From sSéa@ljutcp.hamradio.si Fri Sep 01 10:33:35 1995 

Received: from ljutcp.hamradio.si (radio.kud-fp.si [193.2.132.80]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id KAA10340 for <hfsig@tapr.org>; Fri, 1 
Sep 1995 10:33:14 -0500 

Date: Fri, 01 Sep 95 15:19:31 UTC 

Message-Id: <79158@ljutcp.hamradio.si> 

From: Marijan Miletic <s56a@ljutcp.hamradio.si> 

To: hfsig@tapr.org 

Subject: FFT v. MAC 


I am amzed by KA9Q FFT results on Pentium as his times are beter than many DSP 
chips with hardware buterflies! I wonder what kind of performance one can 
expect for ubiquitous Multiply_And_Accumulate filter function with two pointers 
parallel update? I tried to get this info from many RISC manufacturers to no 
avail. 

I greatly enjoy this conference and this is my first humble posting. I am 
involved in FFT DSP decoding of HF Morse signals with some good results in 1990 


73 de Mario, S56A, N1YU. 
From FORRERJ@frl.orst.edu Fri Sep 01 12:10:08 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id MAA11463 for <hfsig@tapr.org>; Fri, 1 
Sep 1995 12:10:00 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id KAAQ8522 for <hfsig@tapr.org>; Fri, 1 Sep 1995 
10:09:45 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

1 Sep 95 10:16:30 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 1 Sep 95 10:16:13 PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Fri, 1 Sep 1995 10:16:04 PST8PDT 
Subject: Re: [HFSIG:572] FFT v. MAC 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <10413876469@frl.orst.edu> 
Hi Mario, 


Welcome again! I am pleased to hear from you. It appears that HFSIG draws 
from many disciplines - really amazing. 


I think Phil is showing that DSP has become possible on the higher-end 
Intel platforms and, no doubt, we will hear more of this in the future. 
There is also the P55C to watch - Intel promises that it will be a prospect 
for "low-end" DSP applications for portable computers, i.e., modems, FAX, 
and sound etc. I have not seen much on it - it may well have MAC 
capabilities. 


One often see the question coming up about such programs as Baycom 
running under Linux or Windows and the point being made that it's not 
viable because of the high demand on the processor. Although this is true 


if the low-level code is run from a high-end interface, i.e., in a "DOS 
box". If, however, this code is re-written to run at the lowest ring, and 
make use of the advanced hardware that is available, it probably will work 
just fine without to much of a load on the CPU. When working at this 

level of the OS, the problem is that one have to give up the safety 

net offered by the OS, i.e. crash and memory protection - in addition, 
programming at that level is very challenging to say the least, though it 
could be done. Perhaps that is were our feature challenge lays: doing this 
with the least amount of hassle. I suspect that it only need to take one 
good example to show how this is done - anyone ready for a good challenge? 


--Johan 

From karn@qualcomm.com Fri Sep 01 20:38:31 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id UAA19072 for <hfsig@tapr.org>; Fri, 1 
Sep 1995 20:38:25 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
SAA08135; Fri, 1 Sep 1995 18:38:23 -0700 

Date: Fri, 1 Sep 1995 18:38:23 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509020138.SAA08135@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <79158@ljutcp.hamradio.si> (message from Marijan Miletic on Fri, 1 
Sep 1995 10:42:25 -0500) 

Subject: Re: [HFSIG:572] FFT v. MAC 


>I am amzed by KA9Q FFT results on Pentium as his times are beter than many DSP 
>chips with hardware buterflies! I wonder what kind of performance one can 


Yup, I keep questioning the need for special purpose processors given 
the rapidly increasing performance (and declining costs and expanding 
availability) o£ general purpose CPUs. But people keep on talking 
about building TNCs and DSP coprocessors, so I thought I'd convince 
them with an example. :-) 


Last night I went even faster: 333 microseconds (vs yesterday's 380). 


Again, this is for a decimation-in-frequency 256-point radix-4 complex 
FFT in single-precision (32-bit) floating point. The output is left in 
bit-reversed order; it can be restored to normal order with a separate 
routine. Since an important use of the FFT is fast convolution with a 
fixed impulse response, the DIF FFT is more useful than the 
decimation-in-time FFT since you can bit-reverse the transform of the 
impulse response, do your frequency-domain multiplies in bit-reversed 
order and then do the IFFT while avoiding realtime bit reversals 
altogether. 


The speed of my FFT comes from two radix-4 butterfly routines in 
assembler. One does a general 4-point butterfly given a starting 
point, a step between elements, and a step between twiddle factors in 
a lookup table. The other does a "simple" 4-point butterfly on 
adjacent operands without twiddles. This is an important special case 
as the last stage of a DIF consists entirely of them. 


The trick is in keeping the Pentium's 3-stage floating point pipeline 
as full as possible. It really is like juggling with 3 balls in the 
air at once, being careful to give each ball its allotted time in the 
air. 


Driving these assembler routines are a family of C routines that 
operate recursively. For example, the 16-point FFT routine calls the 
general radix-4 butterfly 4 times, then it calls the simple 4-point 
butterfly four times. The 64-point FFT routine calls the general radix 
4 routine 16 times, and then it calls the 16-point routine 4 times on 
the results, with each 16-point call operating as described above. 


This may seem like more overhead than the usual Cooley-Tukey FFT 
structure with nested loops, but each radix-4 butterfly does enough to 
make the call/return overhead almost nil. (One of several reasons to 
do radix-4, btw). It gives a nice elegant structure to the code, but 
more importantly it changes the memory reference patterns so as to 
improve the performance of the cache. Franklin Antonio pointed out to 
me that the normal Cooley-Tukey structure accesses memory 
sequentially, which is just about pessimal from a cache 

standpoint. The recursive structure tends to work on one area of 
memory as long as possible, which greatly improves the cache hit 
ratio. 


This isn't important for small FFTs, but it is important for big 
ones. Before I updated my asm code last night, I was doing megapoint 
(1024x1024) CFFTs in about 18.5 seconds. (I haven't timed the new asm 
code on big arrays yet, but if the speedup is proportional I'd expect 
about 16 seconds.) This makes it a serious contender for the racks of 
special purpose hardware the SETI folks have built over the past ten 
years. Now that Congress has cancelled NASA's SETI funds, maybe this 
stuff could be useful to the amateur groups who are taking up the 
effort. 


Phil 


From karn@qualcomm.com Fri Sep 01 20:39:05 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id UAA19085 for <hfsig@tapr.org>; Fri, 1 
Sep 1995 20:39:01 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
SAA08147; Fri, 1 Sep 1995 18:39:00 -0700 

Date: Fri, 1 Sep 1995 18:39:00 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509020139.SAA08147@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <79158@ljutcp.hamradio.si> (message from Marijan Miletic on Fri, 1 
Sep 1995 10:42:25 -0500) 

Subject: Re: [HFSIG:572] FFT v. MAC 


>expect for ubiquitous Multiply_And_Accumulate filter function with two pointers 


That's my next target. Again, the trick will be in keeping the Pentium's 
pipeline full. 


Phil 

From karn@qualcomm.com Fri Sep 01 20:46:15 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id UAA19182 for <hfsig@tapr.org>; Fri, 1 
Sep 1995 20:46:04 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
SAA08167; Fri, 1 Sep 1995 18:46:01 -0700 

Date: Fri, 1 Sep 1995 18:46:01 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509020146.SAA08167@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <10413876469@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 

Subject: Re: [HFSIG:573] Re: FFT v. MAC 


>One often see the question coming up about such programs as Baycom 
>running under Linux or Windows and the point being made that it's not 
>viable because of the high demand on the processor. Although this is true 
>if the low-level code is run from a high-end interface, i.e., in a "DOS 
>box". If, however, this code is re-written to run at the lowest ring, and 
>make use of the advanced hardware that is available, it probably will work 


The xonlyx thing that needs to run at "low ring" (or more likely at 
interrupt time) is a simple FIFO buffering routine that keeps raw data 
from being lost (on input) or queues from draining (on output) due to 
scheduler delays. Everything else (software modems, protocols, etc) 
will run just fine at normal task level. 


As long as the low-level buffers are large enough to accomodate the 
amount of raw data (audio samples, etc) between scheduling ticks of 
the OS, everything should run quite smoothly. 


All this assumes you have enough total CPU cycles to run everything 
that has to be run. If you don't, then the level at which you run your 
modem won't make any difference. 


Phil 


From danie.brynard@pixie.co.za Sat Sep 02 10:05:57 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id KAA25500 for <hfsig@tapr.org>; Sat, 2 Sep 1995 
10:05:44 -0500 

Received: from pixie.co.za ([196.11.63.144]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id RAA23110 for <hfsig@tapr.org>; Sat, 2 Sep 1995 17:06:23 +0200 

Date: Sat, 2 Sep 1995 17:06:23 +0200 

Message-Id: <199509021506.RAA23110@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 


From: danie.brynard@pixie.co.za (Danie Brynard) 
Subject: Re: [HFSIG:574] Re: FFT v. MAC 


>> 

>Yup, I keep questioning the need for special purpose processors given 
>the rapidly increasing performance (and declining costs and expanding 
>availability) of general purpose CPUs. But people keep on talking 
>about building TNCs and DSP coprocessors, so I thought I'd convince 
>them with an example. :-) 

> 


Interesting Phil. 
1) I suppose my 486DX2-66 is way to slow for any 'DSP' attemp in realtime ? 


2) Why don't you implement a AFSK modem for 1200baud packet on the Pentuim 
to prove the usefulness of your programs ? It could interface to your NOS 
s/w...The comport must connect virtually directly to the radio.. 


73 danie 


From forrerj@ucs.orst.edu Sat Sep 02 15:04:33 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id PAA29015 for <hfsig@tapr.org>; Sat, 2 Sep 1995 
15:04:27 -0500 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA14853; Sat, 2 Sep 1995 13:04:20 -0700 
Message-Id: <9509022004.AA14853@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 02 Sep 1995 13:07:17 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:577] Re: FFT v. MAC 


>>> 

>>Yup, I keep questioning the need for special purpose processors given 
>>the rapidly increasing performance (and declining costs and expanding 
>>availability) of general purpose CPUs. But people keep on talking 
>>about building TNCs and DSP coprocessors, so I thought I'd convince 


>>them with an example. :-) 
>> 

> 

>Interesting Phil. 

> 


>1) I suppose my 486DX2-66 is way to slow for any 'DSP' attemp in realtime ? 
> 

>2) Why don't you implement a AFSK modem for 1200baud packet on the Pentuim 
>to prove the usefulness of your programs ? It could interface to your NOS 


>s/w...The comport must connect virtually directly to the radio.. 
> 

>73 danie 

> 

> 


Wow, I am really impressed Phil - keep up the good work. 


Just another two-cents worth: I just have a couple of things that I have 
been thinking about. 


1) I note that you are running BSD, but wonder what you have in mind for the 
rest of the application, like I/O drivers and the user interface (UI)? 


I have managed to port some sound card DSP applications to run on the 
X-platform under Linux, and I must admit, I really enjoy the real-time 
performance in conjunction with the pretty UI. Linux offers a number of 
mechanisms (three that I am aware of) to do real time work, however, none is 
very easy. Win95 has similar prospects, though I have not yet gotten that 
far yet. 


2) The price/performance of a high-end processor is very appealing (I was 
looking at the 133 MHz P5 motherboards - they are now in the order of 
$1300). If we look a bit further down the line at the possibility of doing a 
full radio modem, for example, perhaps some additional considerations beside 
raw horsepower may be necessary. I am thinking here about timing resources 
sources - it has to be very reliable and accurate. A relatively simple ARQ 
protocol like AMTOR or Pactor for example, relies entirely on good timing, 
i.e., in the order of 30 ppm (CCIR calls for 50 ppm for SITOR). The prospect 
of raw horsepower, in my opinion, puts the cherry on the cake as then you 
can freely implement exotic ECC and symbol sync. schemes without running out 
of steam as often is the case. Obtaining such good timing references off PC 
platforms is possible, however, though not as simple as one might expect. 


I have seen some mention of a version of SPOX for the P55C. That probably 
will provide all the necessary inter task communications mechanisms, timing, 
and scheduling you need. And probably co-exist on the same platform as the 
mainstream GUI OS. 


Has anyone heard anything more about these developments besides the vague 
announcements in the press about Intel's NSP? 


--Johan 


From karn@qualcomm.com Sun Sep 03 01:20:24 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id BAA01942 for <hfsig@tapr.org>; Sun, 3 
Sep 1995 01:20:21 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
XAA16187; Sat, 2 Sep 1995 23:20:19 -0700 

Date: Sat, 2 Sep 1995 23:20:19 -0700 

From: Phil Karn <karn@qualcomm. com> 


Message-Id: <199509030620.XAA16187@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199509021506.RAA23110@foxbat.pix.za> (danie.brynard@pixie.co.za) 
Subject: Re: [HFSIG:577] Re: FFT v. MAC 


My pentium does FFTs "only" 100x faster than necessary to handle data 
sampled at 9600 Hz. I haven't run any tests, but I suspect even a 
DX2-66 can run with cycles to spare. And you can always pop ina 
DX4-100 if you like. 


>2) Why don't you implement a AFSK modem for 1200baud packet on the Pentuim 


Why bother implementing a modem that was obsolete before it was even 
adopted by amateur packet radio? :-) I'd rather concentrate on 
something more efficient. Today I prototyped a piccolo modulator. You 
specify symbol rate, bits/symbol, first tone frequency and tone 
interval. Uses a Kaiser window with specified beta to shape each 
symbol; it's interesting to listen to the difference this makes. 


The Kaiser window has a parameter, beta, that controls the tradeoff between 
main lobe width and sidelobe amplitude. beta=0 corresponds to a rectangular 
window, i.e., no window at all. beta=3.86 is roughly equivalent to a Von Hann 
window, while beta=7 corresponds to a Blackman window. 


BTW, Jim Kaiser and I were in the same group at Bellcore in the mid 1980s. 
A very nice and helpful guy. I think he retired some time ago. 


Phil 

From karn@qualcomm.com Sun Sep 03 01:25:57 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id BAAQ2026 for <hfsig@tapr.org>; Sun, 3 
Sep 1995 01:25:51 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
XAA16195; Sat, 2 Sep 1995 23:25:48 -0700 

Date: Sat, 2 Sep 1995 23:25:48 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509030625.XAA16195@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <9509022004.AA14853@ucs.orst.edu> (forrerj@ucs.orst.edu) 
Subject: Re: [HFSIG:578] Re: FFT v. MAC 


Johan, 


>1) I note that you are running BSD, but wonder what you have in mind for the 
>rest of the application, like I/O drivers and the user interface (UI)? 


I'm currently using a Soundblaster 16 driver that I hacked into KA9Q NOS 
a while ago. My BSDI system talks to it over the house ethernet using 

a TCP connection. I'm doing that for expediency until I find (or write) 
a Soundblaster 16 driver for BSDI. Or switch to Linux/FreeBSD/NetBSD. 


The driver doesn't have to do much -- just buffer raw samples and 
provide hooks to the app for setting the SB16 operating mode and mixer 


settings. 


Funny you should mention timing. A bunch of us recently obtained some 
surplus GPS receivers that we're adapting to PC clock-setting, among 
other uses. Even without a local GPS receiver , I can set my BSDI 
system's clock to within a few ms by firing up NTP, the Internet 
Network Time Protocol. 


Phil 
From jmorriso@bogomips.ee.ubc.ca Sun Sep 03 14:31:22 1995 
Received: from rflab.ee.ubc.ca (ni45.net.ubc.ca [137.82.239.47]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id OAAQ7874 for <hfsig@tapr.org>; Sun, 3 Sep 1995 
14:30:46 -0500 
Received: from bogomips.ee.ubc.ca by rflab.ee.ubc.ca with uucp 
(Linux Smail3.1.28.1 #1) id mOspKkc-Q000R3C; Sun, 3 Sep 95 12:30 PDT 
Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 48) 
id mOspK2Q-Q00TsoC; Sun, 3 Sep 95 11:45 PDT 
Message-Id: <mOspK2Q-000TsoC@bogomips.ee.ubc.ca> 
From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) 
Subject: Re: [HFSIG:580] Re: FFT v. MAC 
To: hfsig@tapr.org 
Date: Sun, 3 Sep 1995 11:45:01 -0800 (PDT) 
In-Reply-To: <199509030625.XAA16195@servo.qualcomm.com> from "Phil Karn" at Sep 3, 
95 01:39:09 am 
X-Linux: Linux 95 "Helsinki" shipping now! Double your money back guarantee! 
X-Bogomips: 33.55 
X-Mailer: ELM [version 2.4 PL22] 
Content-Type: text 
Content-Length: 1047 


Johan, 


I'm currently using a Soundblaster 16 driver that I hacked into KA9Q NOS 
a while ago. My BSDI system talks to it over the house ethernet using 

a TCP connection. I'm doing that for expediency until I find (or write) 
a Soundblaster 16 driver for BSDI. Or switch to Linux/FreeBSD/NetBSD. 


VV VV VV MV 


Linux/FreeBSD/NetBSD share the same sound card drivers (the driver started 
life under Linux, then it was ported. It appears to have been ported to 
SCO and UnixWare too). They also share the 387 math emulator as well 
(unless the BSD guys backed it out political reasons). 


Too bad Linux/FreeBSD/NetBSD don't share the same amateur radio 


networking code. People seem to have gone in different directions in 
that area. 


jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From forrerj@ucs.orst.edu Sun Sep 03 18:47:07 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id SAAQ9776 for <hfsig@tapr.org>; Sun, 3 Sep 1995 
18:47:04 -0500 
Received: from p06.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AAQ6646; Sun, 3 Sep 1995 16:46:55 -0700 
Message-Id: <9509032346.AA06646@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 03 Sep 1995 16:49:58 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:579] Re: FFT v. MAC 


Phil, 


> Today I prototyped a piccolo modulator. You 

>specify symbol rate, bits/symbol, first tone frequency and tone 

>interval. Uses a Kaiser window with specified beta to shape each 

>symbol; it's interesting to listen to the difference this makes. 

> 

>The Kaiser window has a parameter, beta, that controls the tradeoff between 
>main lobe width and sidelobe amplitude. beta=0 corresponds to a rectangular 
>window, i.e., no window at all. beta=3.86 is roughly equivalent to a Von Hann 
>window, while beta=7 corresponds to a Blackman window. 


Very interesting. A couple of us recently had a private go-around on this 
topic that proved to be very educational (to me at least). It mainly 
concerend the rationale behind Dolph-Chebychev window shapes. I am grateful 
to Frode for bringing some notes by Harris regarding this topic to my 
attention. This has to do with how these filter shapes affect dynamic range 
when using the DFT in multitone systems. It is a bit involved for causual 
explanations in a few paragraphs, but I am sure the topic will come up in 
future. AS you say, one can hear the difference by ear. How about bringing 
some of your findings to the DCC and we can compare notes? 


>>BTW, Jim Kaiser and I were in the same group at Bellcore in the mid 1980s. 
>A very nice and helpful guy. I think he retired some time ago. 


An extraordinary opportunity, Phil. What was the incentive for Kaiser's 
work? The Dolph-Chebychev work came about when Dolph was designing multiple 
antenna arrays and was optimizing main lobe vs. sidelobe patterns of such 
arrays. Neat eh? Is'nt it wonderful how mathematics find it's way into 
everything? 


--Johan 


From karn@qualcomm.com Tue Sep 05 04:11:19 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id EAA32179 for <hfsig@tapr.org>; Tue, 5 
Sep 1995 04:11:12 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id CAA01253 
for hfsig@tapr.org; Tue, 5 Sep 1995 02:11:10 -0700 

Date: Tue, 5 Sep 1995 02:11:10 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509050911.CAA0Q1253@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: more Pentium DSP figures 


I'm now down to 318 microseconds on my 256-point CFFT, thanks to some minor 
tweaking of the complex multiply code sequences. 


I came up with a pipelined FIR multiply-accumulate sequence for the 
Pentium that should execute in 3 clocks/tap once the pipe comes up to 
speed. I coded up a 16-tap version in assembler along with a C driver 
to test it. It takes 7.24 seconds to execute the 16-tap FIR routine in 
a loop 10 million times. That works out to about 22.1 million 
single-precision multiply-accumulates per second. At 3 clocks/tap ona 
Pentium 90 that should be 30 million, so if you figure the difference 
is due to loop overhead that's just about what I expected. Longer 
filters should asymptotically approach 30 million taps/sec. 


Who needs DSPs chips? :-) 


Phil 

From karn@qualcomm.com Tue Sep 05 22:09:39 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id WAA16096 for <hfsig@tapr.org>; Tue, 5 
Sep 1995 22:09:33 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
UAAO9280; Tue, 5 Sep 1995 20:09:31 -0700 

Date: Tue, 5 Sep 1995 20:09:31 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509060309.UAAQ9280@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <9509032346.AA06646@ucs.orst.edu> (forrerj@ucs.orst.edu) 
Subject: Re: [HFSIG:582] Re: FFT v. MAC 


Well, I don't know about Dolph and Chebyshev, but Kaiser did his work 
for the same reason as Hamming, Von Hann, Blackman, et al -- to 
provide a way to knock down the nasty sidelobes you get from Fourier 
transforming a finite-time signal with rectangular windowing. You'll 
usually find a discussion of Kaiser windows along with the others in 
most DSP textbooks. 


The Kaiser window is not as popular as the others probably because it 
is more complex to evaluate. Among other things, you need the i0() 
function (zeroth-order modified bessel function of the first kind), 
which is not in most math routine libraries. But the Kaiser window is 


the only one I know of with a built-in knob that lets you vary the 
tradeoff between sidelobe height and main lobe width. You can go all 
the way from rectangular (i.e., no) window with beta=0 to something 
approximating a Blackman window at beta=7 with a fairly wide (~3x) 
main lobe but with sidelobes down more than 60dB. 


Ordinarily you have to switch between entirely different windows to do 
this, and you only get a few discrete choices. Kaiser gives you a 
continuous range. 


These windows have lots of uses, including controlling spectral 
"leakage" in FFTs of continuous sample streams, designing FIR filters 
(see Rabiner & Gold for a good discussion of using the Kaiser window 
here), and designing communication signal pulse shapes. I suppose they 
might even be useful in designing antennas. All these situations 
involve making inherent tradeoffs between sidelobe amplitudes and 
mainlobe widths. 


Those of you who might have heard of K. Feher's supposedly brilliant 
and non-obvious (and patented) nonlinear filter for PSK and MSK 
spectrum control should now recognize it as nothing more than 
windowing each data pulse with a von Hann window, i.e., a half cosine 
-- something that's been in the literature for decades. Funny how the 
same old math keeps getting rediscovered by newcomers. At least Cooley 
and Tukey didn't try to patent the FFT when they (re)discovered it in 
the mid 1960s -- it turns out that the algorithm can be traced all the 
way back to Gauss in the early 1800s! 


Phil 
From alanb@tsnake2.sr.hp.com Wed Sep 06 16:31:12 1995 
Received: from hp.com (hp.com [15.255.152.4]) by sys1.tapr.org (8.6.12/8.6.9) with 
ESMTP id QAA00462 for <hfsig@tapr.org>; Wed, 6 Sep 1995 16:31:04 -0500 
Received: from srmail.sr.hp.com by hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA286663049; Wed, 6 Sep 1995 14:30:52 -0700 
Received: from tsnake2.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ91113044; Wed, 6 Sep 1995 14:30:45 -0700 
Received: by tsnake2.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA190673040; Wed, 6 Sep 1995 14:30:40 -0700 
From: Alan Bloom <alanb@tsnake2.sr.hp.com> 
Message-Id: <199509062130.AA190673040@tsnake2.sr.hp.com> 
Subject: Re: [HFSIG:584] Re: FFT v. MAC 
To: hfsig@tapr.org (Phil Karn) 
Date: Wed, 6 Sep 1995 14:30:39 -0800 (PDT) 
In-Reply-To: <199509060309.UAA09280@servo.qualcomm.com> from "Phil Karn" at Sep 5, 
95 10:26:32 pm 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 904 


Phil wrote: 
> 


These windows have lots of uses, including controlling spectral 
"leakage" in FFTs of continuous sample streams, designing FIR filters 
(see Rabiner & Gold for a good discussion of using the Kaiser window 
here), and designing communication signal pulse shapes. 


VVV WV 


I've been playing around with MathCad to see how big an FIR filter I 
need to implement a root raised cosine filter, such as is used to 
reduce the transmitted bandwidth of many digital modulation modes. 
With an alpha=0.15 filter, simply truncating the impulse response 

at 16 symbols wide results in about -33 dB sidelobes. 


Now I'm about to try different windowing functions. Before I re-invent 
the wheel, can anyone just tell me what's the best window to use for 
minimum sidelobes? What I care about is the worst-case number. Reducing 
far-out sidelobes doesn't do me any good if a closer one is higher. 


AL N1AL 


From karn@qualcomm.com Wed Sep 06 21:19:46 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id VAA04388 for <hfsig@tapr.org>; Wed, 6 
Sep 1995 21:19:42 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
TAA20272; Wed, 6 Sep 1995 19:19:39 -0700 

Date: Wed, 6 Sep 1995 19:19:39 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509070219.TAA20272@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199509062130.AA190673040@tsnake2.sr.hp.com> (message from Alan Bloom 
on Wed, 6 Sep 1995 16:43:31 -0500) 

Subject: Re: [HFSIG:585] Re: FFT v. MAC 


There is no fixed answer to your question. You also need to consider 
how much passband ripple and how wide a passband/stopband transition 
region you're willing to tolerate. 


The Remez exchange algorithm seems to be the preferred way to design FIR 
filters, mainly because it's readily adaptable to arbitrary shapes and 
can add controlled ripple. 


Phil 
From forrerj@ucs.orst.edu Wed Sep 06 22:05:01 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id WAAQ5095 for <hfsig@tapr.org>; Wed, 6 Sep 1995 
22:04:57 -0500 
Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA16870; Wed, 6 Sep 1995 20:04:43 -0700 
Message-Id: <9509070304.AA16870@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 


Date: Wed, 06 Sep 1995 20:08:05 -0800 

To: hfsig@tapr.org 

From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:585] Re: FFT v. MAC 


Al, 


>Phil wrote: 

>> 

>> These windows have lots of uses, including controlling spectral 

>> "leakage" in FFTs of continuous sample streams, designing FIR filters 
>> (see Rabiner & Gold for a good discussion of using the Kaiser window 
>> here), and designing communication signal pulse shapes. 


>I've been playing around with MathCad to see how big an FIR filter I 
>need to implement a root raised cosine filter, such as is used to 
>reduce the transmitted bandwidth of many digital modulation modes. 
>With an alpha=0.15 filter, simply truncating the impulse response 

>at 16 symbols wide results in about -33 dB sidelobes. 

> 

>Now I'm about to try different windowing functions. Before I re-invent 
>the wheel, can anyone just tell me what's the best window to use for 
>minimum sidelobes? What I care about is the worst-case number. Reducing 
>far-out sidelobes doesn't do me any good if a closer one is higher. 

> 

>AL NIAL 

> 

> 


You may want to look at Fred Taylor's book: Digital Filter Design Handbook. 
Dekker, ISBN 0-8247-1357-5. Chaper 5 is devoted to this topic - Pages 
150,151 shows a number of windows and how they trade off characteristics. He 
also shows how to compute the Kaiser window. 


Another excellent source of information that will definately be of interest 
to you, is H.D. Helm's paper: Digital Filters with Equiripple or Minimax 
responses. IEEE Trans. on Audio and Electroacustics. VOL. AU-19, No.1 March 
1971. p:87-93 - this will lead you to the Dolph-Chebychev work. Essentially 
lets you specify the frequency domain response then perform an IFFT folowed 
by Dolph-Chebychev smoothing, to balance the response for time domain filter 
coefficients. Only a couple of lines of Matlab. 


Hope this helps. 


--Johan 


From sSéa@ljutcp.hamradio.si Thu Sep 07 01:57:48 1995 

Received: from ljutcp.hamradio.si (radio.kud-fp.si [193.2.132.80]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id BAAO7767 for <hfsig@tapr.org>; Thu, 7 
Sep 1995 01:57:44 -0500 


Date: Thu, 07 Sep 95 06:47:52 UTC 

Message-Id: <80535@ljutcp.hamradio.si> 

From: Marijan Miletic <s56a@ljutcp.hamradio.si> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:583] more Pentium DSP figures 

In-Reply-To: your message of Tue Sep 05 04:17:55 1995 
<199509050911.CAAQ1253@servo.qualcomm. com> 


Hi HF-SIG's, 
Thanks for a kind support of my first posting in this conference. 


Once again, I am amazed by KA9Q MAC figures. Even with more taps, 

I am sure all the coefficients and circular data buffer might be kept in 
cache for quick pipeline filling. MAC assembler loop is short enough to 
fit separate instruction pipeline and out comes 30 MTS! 


Although Pentium floating point processor is 3 times faster than 486, 
I feel lot of useful audio range DSP can be done even by my old 486/33. 


>Who needs DSPs chips? :-) 
They seem to be good bit fidlers! 


73 de Mario, S56A, N1YU. 
From mcdermot@rdxsunhost.aud.alcatel.com Thu Sep 07 07:40:11 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id HAA09926 for <hfsig@tapr.org>; Thu, 7 
Sep 1995 07:40:02 -0500 
Received: from rdxsunhost.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQ3282; Thu, 7 Sep 95 07:39:58 CDT 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com (4.1/SMI-4.1) 
id AA12749; Thu, 7 Sep 95 07:39:57 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ1752; Thu, 7 Sep 95 07:39:57 CDT 
Date: Thu, 7 Sep 95 07:39:57 CDT 
From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9509071239.AA0Q1752@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:585] Re: FFT v. MAC 


Phil wrote: 

> 

These windows have lots of uses, including controlling spectral 
"leakage" in FFTs of continuous sample streams, designing FIR filters 
(see Rabiner & Gold for a good discussion of using the Kaiser window 
here), and designing communication signal pulse shapes. 


VVV Vv 


I've been playing around with MathCad to see how big an FIR filter I 
need to implement a root raised cosine filter, such as is used to 
reduce the transmitted bandwidth of many digital modulation modes. 
With an alpha=0.15 filter, simply truncating the impulse response 


VV VV VV VV VV MV 


at 16 symbols wide results in about -33 dB sidelobes. 


Now I'm about to try different windowing functions. Before I re-invent 
the wheel, can anyone just tell me what's the best window to use for 
minimum sidelobes? What I care about is the worst-case number. Reducing 
far-out sidelobes doesn't do me any good if a closer one is higher. 


AL N1AL 


VVVV VV VV VV 


Al: I have implemented compensated- and uncompensated root-cosine 
FIR filters with excellent sidelobe supression with 31 taps, using a version 
of the Remez-exchange code that I have modified for various transition band 
shapes. Commercially I have seen it done with as few as 24 taps. Windowing 
functions, such as Hamming and Hanning windows can give good out-of-band 
supression, but at the expense of transition-band distortion, which results 
in eye-pattern closure, in my case, about 1 - 2 dB. 


I have written a book that TAPR will publish this fall, "Handbook of 
RF Modem Theory and Design" which covers this subject in some detail, and I 
include a disk with my modified Remez-exchange software. The modifications 
consist of adding raised cosine, root raised-cosine, and sinc()-compensated 
root 
raised cosine filter shapes. I have plots of frequency response and eye 
pattern 
for several cases of impulse response windowing. I also include Excel 5.0 
spreadsheets for generating eye pattern from impulse/frequency response. 


These were done for alpha's in the range 0.4 to 0.8. At an alpha 
of 0.15, the filter may have to be longer, but this may not be real practical 
since low-alpha filters require more careful frequency response shaping, 
including other factors, such as channel response, IF filter response, and any 
other distortions, such as AF channel response. 


- Tom, N5SEG 
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Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
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From alanb@tsnake2.sr.hp.com Thu Sep 07 13:55:04 1995 
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id NAA11738 for <hfsig@tapr.org>; Thu, 7 Sep 1995 
13:54:54 -0500 
Received: from srmail.sr.hp.com by relay.hp.com with ESMTP 

(1.37.109.16/15.5+ECS 3.3) id AAQ82860079; Thu, 7 Sep 1995 11:54:40 -0700 
Received: from tsnake2.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 


(1.37.109.16/15.5+ECS 3.3) id AA109880078; Thu, 7 Sep 1995 11:54:39 -0700 
Received: by tsnake2.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA118020078; Thu, 7 Sep 1995 11:54:38 -0700 
From: Alan Bloom <alanb@tsnake2.sr.hp.com> 
Message-Id: <199509071854.AA118020078@tsnake2.sr.hp.com> 
Subject: Re: [HFSIG:589] Re: FFT v. MAC 
To: hfsig@tapr.org (Tom Mcdermott) 
Date: Thu, 7 Sep 1995 11:54:37 -0800 (PDT) 
In-Reply-To: <9509071239.AA01752@eagle.aud.alcatel.com> from "Tom Mcdermott" at 
Sep 7, 95 07:52:47 am 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 710 


From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
From: forrerj@ucs.orst.edu (Johan Forrer) 
From: Phil Karn <karn@qualcomm. com> 


Thanks Tom, Johan and Phil. Yesterday I tried windowing the 0.15 alpha 
root-raised-cosine filter's impulse response with a simple Hanning 
window (16 symbol width stretched by the window to 32) and got -58 dB 
worst-case stopband ripple. Worst-case error in the frequency response 
was 0.25 dB up to 1.1 Fn. 


That seems pretty good for a first try. A window with a little narrower 
main lobe in the frequency response should give better pass band 
accuracy. Perhaps a Dolph-Chebyshev, or a Kaiser (if I can find 

the reference for Bessel functions!) 


Thanks again, 
Alan 


From mcdermot@rdxsunhost.aud.alcatel.com Thu Sep 07 14:55:26 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id 0AA12069 for <hfsig@tapr.org>; Thu, 7 
Sep 1995 14:55:20 -0500 
Received: from rdxsunhost.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA24475; Thu, 7 Sep 95 14:30:39 CDT 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com (4.1/SMI-4.1) 
id AA27051; Thu, 7 Sep 95 14:30:37 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ1936; Thu, 7 Sep 95 14:30:36 CDT 
Date: Thu, 7 Sep 95 14:30:36 CDT 
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9509071930.AA01936@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:590] Re: FFT v. MAC 


> Thanks Tom, Johan and Phil. Yesterday I tried windowing the 0.15 alpha 


root-raised-cosine filter's impulse response with a simple Hanning 
window (16 symbol width stretched by the window to 32) and got -58 dB 
worst-case stopband ripple. Worst-case error in the frequency response 
was 0.25 dB up to 1.1 Fn. 


That seems pretty good for a first try. A window with a little narrower 
main lobe in the frequency response should give better pass band 
accuracy. Perhaps a Dolph-Chebyshev, or a Kaiser (if I can find 

the reference for Bessel functions!) 


Thanks again, 


Alan 


VV VVV VV VV VV VV WV 


Alan: you may find that the eye closure and the maximum error 
in the transition band are not the same, once you hit about the -20 dB 
point in the response, there is not enough energy left to close the eye 
very much, so the error is more important (in terms of eye closure) 
at frequencies lower than that point. 


For 2-level eyes it usually is not much of a problem. For 
multiple-level eyes, it is quite important. 


- Tom, NSEG 
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Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
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From danie.brynard@pixie.co.za Thu Sep 07 23:20:24 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAAQ0740 for <hfsig@tapr.org>; Thu, 7 Sep 1995 
23:20:18 -0500 

Received: from pixie.co.za ([196.11.63.138]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id GAA26506 for <hfsig@tapr.org>; Fri, 8 Sep 1995 06:21:12 +0200 

Date: Fri, 8 Sep 1995 06:21:12 +0200 

Message-Id: <199509080421.GAA26506@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:583] more Pentium DSP figures 


> 

>Who needs DSPs chips? :-) 
> 

Phil, 


However...I need still to be convinced that the CPU can then do anything 
else but the FFT or FIR ? I mean other house keeping would normally be done 
in C or so. Or would it also be coded into ASM ? 


I guess my point is: who will do the housekeeping and what effect will it 
have on the Pentuim doing its DSP stuff now fulltime say for a modem 
implementation ? 


Just asking, I am no boffin. Just following your work with interest. 
73 danie zs6awk 


From karn@qualcomm.com Fri Sep 08 20:49:15 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id UAA15391 for <hfsig@tapr.org>; Fri, 8 
Sep 1995 20:49:12 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
SAA21011; Fri, 8 Sep 1995 18:49:07 -0700 

Date: Fri, 8 Sep 1995 18:49:07 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509090149.SAA21011@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199509080421.GAA26506@foxbat.pix.za> (danie.brynard@pixie.co.za) 
Subject: Re: [HFSIG:592] Re: more Pentium DSP figures 


>However...I need still to be convinced that the CPU can then do anything 
>else but the FFT or FIR ? I mean other house keeping would normally be done 
>in C or so. Or would it also be coded into ASM ? 


Well, let's say you needed to do one 256-pt CFFT on each 512 samples of 
real data that arrive at a 9600 sample/sec rate. That's one FFT every 
53.3 milliseconds. If it takes me 320 us to do one FFT, that's 0.6% of 
the machine's real time. I think I'll have time left to do other things. 


Obviously a real modem will have to do more than just a CFFT, but I 
suspect even after I add the rest of it I'll have plenty of time left. 


Most of the code can be in C. Only a few compute-intensive primitives 
really need to be written in asm language, and even there I don't 
think it's really essential -- it's just neat to see how fast you can 
make them go. 


Phil 


From chbrain@dircon.co.uk Sat Sep 09 03:52:54 1995 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id DAA19278 for <hfsig@tapr.org>; Sat, 9 
Sep 1995 03:52:45 -0500 
Received: by felix.dircon.co.uk id AA20851 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 9 Sep 1995 09:52:34 +0100 
Message-Id: <199509090852.AA20851@felix.dircon.co.uk> 


Received: from ad006.pool.dircon.co.uk(193.128.231.6) by amnesiac via smap (V1.3) 
id sma020849; Sat Sep 9 09:52:08 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 09 Sep 1995 08:47:00 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:580] Re: FFT v. MAC 


> I can set my BSDI 

>system's clock to within a few ms by firing up NTP, the Internet 
>Network Time Protocol. 

> 

>Phil 

> 

> 

Phil what RFC is NTP described in ? 


Regards Charles G4GUO 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From karn@qualcomm.com Sun Sep 10 00:04:39 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id AAA28276 for <hfsig@tapr.org>; Sun, 10 
Sep 1995 00:04:33 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
WAA28725; Sat, 9 Sep 1995 22:04:30 -0700 

Date: Sat, 9 Sep 1995 22:04:30 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509100504 .WAA28725@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199509090852.AA20851@felix.dircon.co.uk> (chbrain@dircon.co.uk) 
Subject: Re: [HFSIG:594] Re: FFT v. MAC 


>Phil what RFC is NTP described in ? 
1305. 


Phil 

From Tom_Beaudry@tvratings.com Mon Sep 11 09:27:03 1995 

Received: from voyager.dun.nielsen.com (voyager.dun.nielsen.com [204.213.128.66]) 
by sysi.tapr.org (8.6.12/8.6.9) with ESMTP id JAA10656 for <hfsig@tapr.org>; Mon, 
11 Sep 1995 09:26:54 -0500 


Received: (from mailsys@localhost) 
by voyager.dun.nielsen.com (8.6.10+/8.6.10) id KAA25489 
for <hfsig@tapr.org>; Mon, 11 Sep 1995 10:26:03 -0400 
Received: from ibis.dun.nielsen.com(138.108.42.7) by voyager.dun.nielsen.com via 
smap (V1.3) 
id smaQ25478; Mon Sep 11 10:25:17 1995 
Received: from mailgate.dun.nielsen.com ([138.108.52.10]) 
by ibis.dun.nielsen.com (8.6.10/8.6.9) with SMTP id KAA14037 
for <hfsig@tapr.org>; Mon, 11 Sep 1995 10:25:05 -0400 
Received: by mailgate.dun.nielsen.com with Microsoft Mail 
id <30547005@mailgate.dun.nielsen.com>; Mon, 11 Sep 95 10:21:09 PDT 
From: "Beaudry, Tom" <Tom_Beaudry@tvratings.com> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:594] Re: FFT v. MAC 
Date: Mon, 11 Sep 95 10:24:00 PDT 
Message-ID: <30547005@mailgate.dun.nielsen.com> 
Encoding: 35 TEXT 
X-Mailer: Microsoft Mail V3.0 


Check the US Naval Observatory's home page for a link to the information 
as well as instructions on how to sync your computer's clock to their's. 
The URL is: 


<http://www.usno.navy.mil/home.html> 


From: hfsig[SMTP:hfsig@tapr.org] 

Sent: Saturday, September 09, 1995 3:55 AM 
To: hfsig 

Subject: [HFSIG:594] Re: FFT v. MAC 


> I can set my BSDI 

>system's clock to within a few ms by firing up NTP, the Internet 
>Network Time Protocol. 

> 

>Phil 

> 

> 

Phil what RFC is NTP described in ? 


Regards Charles G4GUO 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From forrerj@ucs.orst.edu Mon Sep 11 13:10:56 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id NAA13283 for <HFSIG@TAPR.org>; Mon, 11 Sep 1995 
13:10:49 -0500 
Received: from p08.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA13777; Mon, 11 Sep 1995 11:10:27 -0700 
Message-Id: <9509111810.AA13777@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Mon, 11 Sep 1995 11:14:11 -0800 
To: HFSIG@TAPR. org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: HFSIG at DCC 


Hi all, 
I got back from the DCC late last night - lots of exciting bits to share. 


Things are very hectic here at the moment, but I promise to fill you in 
about the main attactions. However, regarding HFSIG's participation, 
congratulations to Pawel on the 15-tone modem - it attracted a lot of 
attention, also Adrian's DSP audio processor was of much interest. 


A special word of thanks to Walt for bringing his computer that we ran the 
demo's on. 


I much appreciated the discussions during the HFSIG discussion - we have 
made progress on some rather difficult issues. 


May I just add that I appreciated the opportunity being at the DCC and 
sincerely thank the organisers, especially TPRS, TAPR, and Greg for hosting 
us and making it a worthwhile experience. 


73's 
--Johan 


From GARRETIJ2@btlip15.bt.co.uk Tue Sep 12 02:19:54 1995 

Received: from zaphod.axion.bt.co.uk (zaphod.axion.bt.co.uk [132.146.5.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id CAA22999 for <HFSIG@TAPR.ORG>; Tue, 12 
Sep 1995 02:19:50 -0500 

Received: from smtpgate.comnet.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); 
Tue, 12 Sep 1995 08:19:35 +0100 

Received: by smtpgate.comnet.bt.co.uk with Microsoft Mail id 
<30553547@smtpgate.comnet.bt.co.uk>; Tue, 12 Sep 95 08:22:47 BST 

From: "Garrett, John, GARRETJ2" <GARRETI2@btlip15.bt.co.uk> 

To: HFSIG@TAPR.ORG 

Subject: [HFSIG:596] Re: FFT v. MAC 

Date: Tue, 12 Sep 95 08:19:00 BST 


Message-ID: <30553547@smtpgate.comnet.bt.co.uk> 
Encoding: 2 TEXT 
X-Mailer: Microsoft Mail V3.0 


Away until 25th September. Please contact Lynn Dunnett on 01473 644859 for 
assistance in my absence. 
From mcdermot@rdxsunhost.aud.alcatel.com Tue Sep 12 07:56:17 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id HAA25422 for <hfsig@tapr.org>; Tue, 12 
Sep 1995 07:56:02 -0500 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 

id AAQ2013; Tue, 12 Sep 95 07:55:36 CDT 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 
(4.1/SMI-4.1) 

id AAQ2466; Tue, 12 Sep 95 07:55:34 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 

id AAQ1669; Tue, 12 Sep 95 07:55:33 CDT 
Date: Tue, 12 Sep 95 07:55:33 CDT 
From: mcdexmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9509121255 .AA01669@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: OFDM equalization 


At the ARRL DCC in Arlington, Texas this weekend, several of 
us had an interesting conversation regarding the 15-carrier QPSK OFDM 
system being designed by Pawel. I had the opportunity to see the 
demonstration, and congratulations are due to Pawel, and crew for 
some very good work. Johan asked if I could describe our conversation. 


During the discussion, the topic of equalization came up, and 
it was noted that because of the different frequency responses of the 
equipment, that the tones did not arrive at the receiver with the 
same amplitude, and this suggested that it might be possible to 
equalize the received signal amplitude within the DSP receive algorithm. 


In the initial transmission phase, I beleive that 4 tones are 
sent so that synchronization can be achieved. It seems that if the 
tones are properly spaced in the passband, then simultaneous with the 
synchronization, the the amplitude of the 4 tones could be measured, 
and then a simple minimal-pole equalizer formulated to compensate for 
non-flat response. Perhaps this might require 5 tones, however. 


On later reflection, I have the following concern, and possible 
solution: 


While this would equalize the receiver variation, and perhaps 
make the FFT that converts the time-waveform to the individual amplitude 
bins somewhat better, if the amplitude distortion is primarily 
occuring at the transmitter, then it does not really solve the problem 
of some of the 15 carriers having poorer signal-to-noise ratio on the 


HF band than other carriers. There is a theorem called the water-pouring- 
principle which states that the best Eb/No performance occurs when the 
transmitter power is equally divided between the carriers. 


So, it seems that possibly an off-line equalization of the 
transmitter might be needed, sort of a utility program that let the 
user record the output power of each of the 15 carriers, and then 
tell the software about those levels. Next, some compensation for that 
could be made, and then an amplitude equalizer programmed (once). 

This equalizer would then be inserted into the transmit side of the 
modem code, resulting in a particular user's transmitter being more 
or less optimally flat versus carrier frequency. 


Now, at the receive side, an adaptive equalization could occur 
during the synchronization time period on receive, and computed, 
then inserted into the receive modem side. This would compensate for 
any receiver non-flatness, and any left-over equalization errors, 
resulting in fewer spill-over effects in the receive side FFT. Of course 
there would have to be care taken that the receiver did not attempt to 
equalize during a selective-fading event, otherwise it might compute 
a poor choice for that frame. But this effect should be corrected next 
frame, or perhaps could be averaged over several frames. 


- Tom, NSEG 

Bete eterna te ntact daitect thet attra ant Moh, aaete al anette a hegeac eae chon an Usaha tae ad stata tee ate RN ea 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
Sch Paccet bec Be cecteeee fie Se See ee See tee ck DNS Pia he BEE LOK Bie ee Ee 


From GARRETIJ2@btlip15.bt.co.uk Wed Sep 13 02:18:37 1995 

Received: from zaphod.axion.bt.co.uk (zaphod.axion.bt.co.uk [132.146.5.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id CAA14948 for <HFSIG@TAPR.ORG>; Wed, 13 
Sep 1995 02:18:33 -0500 

Received: from smtpgate.comnet.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); 
Wed, 13 Sep 1995 08:18:14 +0100 

Received: by smtpgate.comnet.bt.co.uk with Microsoft Mail id 
<30568695@smtpgate.comnet.bt.co.uk>; Wed, 13 Sep 95 08:21:57 BST 

From: "Garrett, John, GARRETIJ2" <GARRETJ2@bt1ip15.bt.co.uk> 

To: HFSIG@TAPR.ORG 

Subject: [HFSIG:598] Re: FFT v. MAC 

Date: Wed, 13 Sep 95 08:19:00 BST 

Message-ID: <30568695@smtpgate.comnet.bt.co.uk> 

Encoding: 2 TEXT 

X-Mailer: Microsoft Mail V3.0 


Away until 25th September. Please contact Lynn Dunnett on 01473 644859 for 
assistance in my absence. 

From forrerj@ucs.orst.edu Fri Sep 15 15:40:45 1995 

Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 


(8.6.12/8.6.9) with SMTP id PAA29022 for <HFSIG@tapr.org>; Fri, 15 Sep 1995 
15:40:35 -0500 

Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA24197; Fri, 15 Sep 1995 13:40:15 -0700 
Message-Id: <9509152040.AA24197@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 15 Sep 1995 13:44:06 -0800 

To: HFSIG@tapr.org 

From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: HFSIG at DCC 


Hi, 


Sorry for taking a while to get a brief summary out - had to take care of 
important business. Here is the promised summary of the DCC. Enjoy! 


The DCC this year was buzzing with activities. Two 
outstanding workshops, excellent papers, and interesting talks on 
amateur radio networking infrastructure developments, future 
satellites, and other digital issues made it a busy time. In 
addition, meeting old friends and the opportunity to make new 
ones is always enjoyable. Not to mention the informal discussions 
over a beer late at night, listening to exciting things taking 
place. Unfortunately, a significant proportion of happenings 
never make it into the proceedings, so it made the extra effort 
to be there all that much more worthwhile. 

Saturday's program consisted of several parallel sessions. 
It was hard to decide which one to participate in as often the 
case may be - in my case I was involved in presenting material as 
well. So keep in mind that I can only relate to what I could fit 
in these busy few hours. The organizers had an excellent idea to 
make room for series of introductory presentations: digital 
communications in general, HF digital, digital satellite 
communivcations, and packet networking. Besides giving beginners 
an opportunity to pick up a wealth of ideas, this also gave local 
amateurs an opportunity to hear what digital communications were 
about. 

After presenting my introductory talk on HF digital, I 
slipped out to hear the end of Frank Perkins' presentation on 
software development issues for the DSP-93. I don't know how many 
really appreciated how successful the DSP-93 modems are - this is 
due to the outstanding efforts of the DSP-93 software developers 
such as Frank. One very useful tip that I picked up from Frank's 
talk was the problem that the "ABS" function introduce when used 
in detectors. The "SQUARED" function is what one need, this is 
because the absolute value of a band-limited signal turns out to 
be not band-limited and subsequently cannot be lowpass filtered. 


In addition Frank had a video tape with sound that made for a 
great presentation. Tom McDermott's talk followed on using Excel 
for evaluating DSP solutions. It was obvious that Tom has 
uncovered a powerful tool for serious DSP work. Using built-in 
Excel functions besides several routines that he developed 
himself, the point-and-click, drag-and-drop metaphors makes quick 
work of analyzing sampled signals. When Tom's book becomes 
available, we will have further opportunities to try these 
ourselves. Looks like a reasonably inexpensively alternative to 
other programs. 

The "HF issues" session and Phase3D talk unfortunately ran 
parallel - we missed a couple of good participants, and I would 
have loved hearing Bdale Garbee's talk. Anyway, we had excellent 
participation on important HF digital issues. I gave brief 
overviews on the status of the HF channel simulator, Adrians's 
MFSK, and Pawel's OFDM modems. The HF ionospheric simulator work 
appears to be of some interest and a few moments was spent on 
that. Paul Rinaldo, W4RI, brought up an interesting idea - how to 
evaluate adjacent channel interference. The Watterson model, for 
example, only deals with the variations due to the ionosphere. It 
would be interesting to have some means for evaluating different 
situations due to other nearby digital transmissions. Phil Karn's 
progress on Pentium-powered DSP was noteworthy and stirred 
interest - that would be an interesting one to watch in future. 
This was followed by a lively discussion on FCC regulations and 
the future of using our proposed multi-tone HF modems. It appears 
that it would be possible to obtain either STA or experimental 
licenses to experiment. Paul kindly offered to help looking into 
this. 

What helped promote our ideas a bit, was the live demo that 
we put on afterwards. Walt, K5YFW, brought his computer that we 
set up to give folks the opportunity to see Pawel's 15-carrier 
modem in operation. Some mentioned that the audio has a striking 
likeness to 300 baud HF packet. Many would be fooled into 
thinking that it was indeed packet - this is because it does not 
sound like a wideband signal at all. I suspect that a demo such 
as this may win many over. We also played with the DSP sound card 
and played with Adrian's, G4ZHZ, signal processing software. I 
think he did a very nice job to package several really nice 
functions, i.e., several CW filters and others for SSB, RTTY, and 
FAX. This also includes a Hilbert transform with which one could 
slide the output audio pitch to wherever audiuo frequency you 
wanted, kind of like a digital BFO. I played some audio from a 
cassette tape and the ability to shift audio in this manner 
without clicks, pops or other artifacts, is really amazing - all 
made possible by DSP. 

There was not very much equipment on display except for 
Paccom that showed a diverse range amateur digital equipment. I 
did however, took a bit of time looking over the new Pactor II 
hardware - the hardware is very well made, and the technology 
very advanced. If you are interested in reading a bit more about 
the technical aspects of this hardware also about some of 
software tricks that makes up Pactor II, be sure to ask the folks 


at Paccom for a data sheet - its very well written. 

I left the best for last - Phil Karn's Saturday evening's 
dinner presentation. In essence, the theme was what the future 
holds for amateur radio, not only the digital modes, but how to 
best utilize our portion of the RF spectrum. A large portion of 
the presentation was devoted to a walk through Phil's Internet 
URL on coding. This is a remarkably well done, common-sense 
audio/visual overview of the mathematical magic of some important 
issues regarding future digital transmission of data and voice: 
bandwidth, power, information theory, and most important, the 
mindset of the average amateur. Phil did an outstanding job 
entertaining us with his vision, and all this with his usual good 
humor. 

Although I had a lot to do on my way home (like working ona 
business plan), nevertheless I could not help but think about the 
impressions that the conference left: the contrast between wide 
band vs. narrow band. I have no doubts in my mind about the 
technological advantages that wide band offers, but what make me 
most excited is to think of all the opportunities that lays ahead 
in digital RF technology and DSP. Would'nt you you agree that 
this is something to look forward to? 

I would like to thanks all the folks that made the 
conference a success: the ARRL and our hosts APRS and TAPR. Well 
done and much thanks. Also to the software developers that helped 
make the demo: Pawel, and the Finn's, Adrian and Walt for 
bringing his computer equipment. Well done. 


Let me know if I missed anything. 
73's 


--Johan, KC7WW 


From forrerj@ucs.orst.edu Sat Sep 16 16:44:37 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id QAA14348 for <HFSIG@tapr.org>; Sat, 16 Sep 1995 
16:44:31 -0500 
Received: from p02.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA28462; Sat, 16 Sep 1995 14:44:25 -0700 
Message-Id: <9509162144.AA28462@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 16 Sep 1995 14:48:21 -0800 
To: HFSIG@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: To: Peter TY1PS 


Hi Peter, 


I have somehow managed to loose your e-mail address. Could you please be so 
kind and e-mail me - I have some further news that might interest you. 


73's 
--Johan 


From danie.brynard@pixie.co.za Sun Sep 17 02:40:52 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id CAA22317 for <hfsig@tapr.org>; Sun, 17 Sep 1995 
02:40:37 -0500 

Received: from net-6.pta.pix.za ([196.11.63.142]) by foxbat.pix.za (8.6.12/8.6.12) 
with SMTP id JAAQ3183 for <hfsig@tapr.org>; Sun, 17 Sep 1995 09:41:41 +0200 
Date: Sun, 17 Sep 1995 09:41:41 +0200 

Message-Id: <199509170741.JAAQ3183@foxbat.pix.za> 

X-Sender: pakO3226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:601] HFSIG at DCC 


>Hi, 

> 

>Sorry for taking a while to get a brief summary out - had to take care of 
>important business. Here is the promised summary of the DCC. Enjoy! 

> 
> 
> 
> The DCC this year was buzzing with activities. Two.... 

Dankie Johan vir die terugvoer. Jy moet my laat weet as enige van die 
‘'talks' op Internet gaan verskyn of bestel kan word per pos. Dit lyk of RF 
digital kommunikasie baie ‘exciting’ tye binnegaan. Ek is ook opgewonde. 
Daar is meer en meer spread spectrum goed aan die gang sien ek. Jy weet 
seker dat mens nogal goedkoop sprei spektrum chippies kan koop deesdae. Ken 
jy bv die STEL-2000A, die S20043 van AMI, die magtige UNISYS chip ens ens 


Van hulle kos selfs hier in ZS so laag as R160 ! Lokaal is daar egter nie 
belangstelling in sulke gevorderde tegnoligie nie hi ! 


Ek het vanoggend weer CW op 40m gewerk na 'n lamg tyd. Ek werk toe 'n ZS21m 
en hy se ‘aangename kennis, is jy nuut op die band ?' ek se toe nee geen my 
net kans my CW sal reg kom hi ! (ons het so 22wpm gewerk) 

groete 

Danie ZS6AWK 

From forrerj@ucs.orst.edu Sun Sep 17 20:24:09 1995 


Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id UAAQ3966 for <hfsig@tapr.org>; Sun, 17 Sep 1995 


20:23:58 -0500 
Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA15572; Sun, 17 Sep 1995 18:23:47 -0700 
Message-Id: <9509180123 .AA15572@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 17 Sep 1995 18:27:50 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:603] Re: HFSIG at DCC 


>>Hi, 

>> 

>>Sorry for taking a while to get a brief summary out - had to take care of 
>>important business. Here is the promised summary of the DCC. Enjoy! 
>> 

>> 

>> 

>> The DCC this year was buzzing with activities. Two.... 

> 

>Dankie Johan vir die terugvoer. Jy moet my laat weet as enige van die 
>'talks' op Internet gaan verskyn of bestel kan word per pos. 


Die "proceedings" is beskikbaar vanaf ARRL (14th DCC). Daar is egter baie 
min inhoud wat werklik daar aangegaan het. Meeste van die artikels in die 
"proccedings" was nie eens voorgedra nie - net ingestuur vir die 
konverensie. Andersins weet ek nie van enige van die praatjies wat 
elektronies beskikbaar gaan wees nie, behalwe Phil se URL op Internet WWW. 


>Dit lyk of RF 

>digital kommunikasie baie ‘exciting' tye binnegaan. Ek is ook opgewonde. 
>Daar is meer en meer spread spectrum goed aan die gang sien ek. Jy weet 
>seker dat mens nogal goedkoop sprei spektrum chippies kan koop deesdae. Ken 
>jy bv die STEL-2000A, die S20043 van AMI, die magtige UNISYS chip ens ens 
>Van hulle kos selfs hier in ZS so laag as R160 ! Lokaal is daar egter nie 
>belangstelling in sulke gevorderde tegnoligie nie hi ! 


Daar was heelwat tyd aan die chips bestee in privaat geselskap. Sal die 
ontwikkelings fyn dophou. 


> 

>Ek het vanoggend weer CW op 40m gewerk na 'n lamg tyd. Ek werk toe 'n ZS21m 
>en hy se 'aangename kennis, is jy nuut op die band ?' ek se toe nee geen my 
>net kans my CW sal reg kom hi ! (ons het so 22wpm gewerk) 

> 

>groete 

> 

>Danie ZS6AWK 

> 


Wou nog iets se i.s. jou vraag oor die EVM en RTTY, maar vroulief het my 
aangejaag dat ons moes vertrek op pad kerk toe. 


Hoe genruik jy jou INT's op die com poorte? Is jy seker dat dit uniek is, 
maw is daar nie 'n moontlikheid dat daar "device" drivers die interrupts 
onderskep nie? Die lyk amper asof jy 'n mouse driver het wat die serie poort 
data onderskep en dink jy beweeg die muis? Jy moet moontlik die mouse drywer 
uithaal uit jou autoexec.? 


Nog 'n idee: hoe skakel jy die poorte om van DEBUG na SCI? Twee kabels na 
die PC, of een kabel van die PC wat jy omruil op die EVM? 


Hoop dit gee 'n paar iedees oor jou probleem, want anders vermoed ek die 
ergste - 'n probleem met jou DSP chip. Hoop nie dis die geval nie. 


Groete tot later, 


--Johan 


From GARRETIJ2@btlip15.bt.co.uk Mon Sep 18 02:18:27 1995 

Received: from zaphod.axion.bt.co.uk (zaphod.axion.bt.co.uk [132.146.5.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id CAA11445 for <HFSIG@TAPR.ORG>; Mon, 18 
Sep 1995 02:18:24 -0500 

Received: from smtpgate.comnet.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); 
Mon, 18 Sep 1995 08:18:09 +0100 

Received: by smtpgate.comnet.bt.co.uk with Microsoft Mail id 
<305D1E1F@smtpgate.comnet.bt.co.uk>; Mon, 18 Sep 95 08:22:07 BST 

From: "Garrett, John, GARRETJ2" <GARRETIJ2@bt1lip15.bt.co.uk> 

To: HFSIG@TAPR.ORG 

Subject: [HFSIG:601] HFSIG at DCC 

Date: Mon, 18 Sep 95 08:18:00 BST 

Message-ID: <305D1E1F@smtpgate.comnet.bt.co.uk> 

Encoding: 2 TEXT 

X-Mailer: Microsoft Mail V3.0 


Away until 25th September. Please contact Lynn Dunnett on 01473 644859 for 

assistance in my absence. 

From dibene@VNET.IBM.COM Mon Sep 18 05:47:47 1995 

Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by sys1.tapr.org 

(8.6.12/8.6.9) with SMTP id FAA13795 for <hfsig@tapr.org>; Mon, 18 Sep 1995 

05:47:41 -0500 

Message-Id: <199509181047 .FAA13795@sys1.tapr.org> 

Received: from ROMVMNIC by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0948; 
Mon, 18 Sep 95 06:47:11 EDT 

Date: Mon, 18 Sep 95 12:42:51 GMT 

From: "Alberto di Bene (xx39-2-596.25744)" <dibene@VNET.IBM. COM> 

To: hfsig@tapr.org 

Subject: Pitch shifting 


> This also includes a Hilbert transform with which one could 


slide the output audio pitch to wherever audiuo frequency you 
wanted, kind of like a digital BFO. I played some audio from a 
cassette tape and the ability to shift audio in this manner 
without clicks, pops or other artifacts, is really amazing - all 
made possible by DSP. 


VV VV WV 


Do you mean that the audio band is shifted (keeping the bandwidth), or 
that it is multiplied by some factor ? 


Do you have more info on this subject ? I have a DSP evaluation board 
with the TMS320C50 and would like to try to implement it. 


Thanks for any info 


73 de 
Alberto di Bene, I2PHD i2phd@amsat.org diben@vnet.ibm.com 


From karn@qualcomm.com Mon Sep 18 12:38:03 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id MAA21838 for <hfsig@tapr.org>; Mon, 18 
Sep 1995 12:37:59 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
KAA26088; Mon, 18 Sep 1995 10:37:56 -0700 

Date: Mon, 18 Sep 1995 10:37:56 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509181737 .KAA26088@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199509181047 .FAA13795@sys1.tapr.org> (dibene@vnet.ibm.com) 
Subject: Re: [HFSIG:606] Pitch shifting 


> Do you mean that the audio band is shifted (keeping the bandwidth), or 
> that it is multiplied by some factor ? 


Shifted, keeping the bandwidth -- just like a SSB receiver. Thats's why 
the Hilbert Transform is required. 


If you compose a complex signal from a real-valued signal as the real 
part and the hilbert transform of the real part as the imaginary part, 
then the fourier transform of the complex signal is one-sided. That 
means you can shift it in frequency (e.g., by multiplying by ejwt) 
without any pesky negative frequencies aliasing around zero back 

into the audio band. 


This is the basis of a phasing-type SSB exciter -- you do the *xe4jwt part 
by running the complex signal into an I/Q modulator and summing the 
results. 


Phasing-type SSB exciters fell by the wayside when crystal filters did 
the job, because they required no careful adjustments. I predict phasing 
will make a comeback now that you can do the job in DSP much better. 


Phil 


From FORRERJ@frl.orst.edu Wed Sep 20 10:25:30 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ4491 for <hfsig@tapr.org>; Wed, 20 
Sep 1995 10:25:26 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAAQ6981 for <hfsig@tapr.org>; Wed, 20 Sep 1995 
08:25:41 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

20 Sep 95 08:32:17 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 20 Sep 95 08:32:04 PST8PDT 
From: "Johan Forrer" <FORRERJ@fxr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 20 Sep 1995 08:31:57 PST8PDT 
Subject: FCC regulations and multitone modems 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <2C1C4B364A@fr1.orst.edu> 
Hi all, 


I did mention that we discussed the legal status of US amateur radio 
operator regarding the use of multitone modems on HF, at the recent DCC. 


I just heard from Chris Imlay, N3AKD in Washinton that he and Paul Rinaldo, 
the ARRL's liason with the FCC, checked the regulations and found no reason 
why we could not use our multitone modems on HF, except for unattended 
operations, where the restriction is now 500 Hz. 


This is good news. I take it from this good authority then that we can 
conduct our experiments on an international basis, something that would 
have been a problem with an STA. 


So, anyone interested in doing local trials for starters? All that is needed 
is a 386/486 computer running NOS, the Motorola EVM, a rather simple PTT 
interface, and appropiate cable to connect your transceiver to the EVM. 


73's 


--Johan, KC7WW 


From karn@qualcomm.com Wed Sep 20 19:10:53 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id TAA14987 for <hfsig@tapr.org>; Wed, 20 
Sep 1995 19:10:49 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
RAA29966; Wed, 20 Sep 1995 17:10:40 -0700 

Date: Wed, 20 Sep 1995 17:10:40 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509210010.RAA29966@servo.qualcomm. com> 


To: hfsig@tapr.org 
In-reply-to: <2C1C4B364A@frl.orst.edu> (FORRERIJ@£r1l.orst.edu) 
Subject: Re: [HFSIG:608] FCC regulations and multitone modems 


Johan, 


I'm confused. Aren't there both subband and bandwidth problems on HF? 
As I understood it, data is not allowed in the voice bands (except for 
digital voice), and down in the CW bands I didn't know we could run 
data with ~3 Khz bandwidths. Have the rules changed recently? I admit 
to not having kept up. 


Phil 

From danie.brynard@pixie.co.za Wed Sep 20 23:53:57 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAA20033 for <hfsig@tapr.org>; Wed, 20 Sep 1995 
23:53:51 -0500 

Received: from net-10.pta.pix.za ([196.11.63.146]) by foxbat.pix.za 
(8.6.12/8.6.12) with SMTP id GAA19796 for <hfsig@tapr.org>; Thu, 21 Sep 1995 
06:55:13 +0200 

Date: Thu, 21 Sep 1995 06:55:13 +0200 

Message-Id: <199509210455.GAA19796@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:604] Re: HFSIG at DCC 


Johan 


>Hoe genruik jy jou INT's op die com poorte? Is jy seker dat dit uniek is, 
>maw is daar nie ‘'n moontlikheid dat daar "device" drivers die interrupts 
>onderskep nie? Die lyk amper asof jy 'n mouse driver het wat die serie poort 
>data onderskep en dink jy beweeg die muis? Jy moet moontlik die mouse drywer 
>uithaal uit jou autoexec.? 


Ja jy is miskien reg ! Ek het vergeet van die device drivers wat daar sit en 
die int vektore verander, sal jou laat weet... 


>Nog ‘'n idee: hoe skakel jy die poorte om van DEBUG na SCI? Twee kabels na 
>die PC, of een kabel van die PC wat jy omruil op die EVM? 


Ek het twee kabels met db9's aan na com1 en com2. My debugger is op com2 en 
die SCI op com1. 


73 Danie 


PS 0 ja wou jou nog se; hulle is besig om 'n 64kbps lyn na ons mpy in te 
sit. Op die staduim het ek reeds Netcape @ 64kbps. Dis fantasties en wil nou 


bietjie ou Phil se .wav ens demo's aflaai op 'n dag. EK kan egter nog nie 
FTP en email nie. Dis nog nie ‘aangeskakel' nie. 


From gjones@tenet.edu Thu Sep 21 00:35:10 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 
by sysi.tapr.org (8.6.12/8.6.9) with ESMTP id AAA21978 for <hfsig@tapr.org>; Thu, 
21 Sep 1995 00:35:07 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 
AAAO8720 for hfsig@tapr.org; Thu, 21 Sep 1995 00:35:06 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199509210535.AAA08720@Leslie-Francis.tenet.edu> 

Subject: Re: [HFSIG:610] Re: HFSIG at DCC 

To: hfsig@tapr.org 

Date: Thu, 21 Sep 1995 00:35:05 -0500 (CDT) 

In-Reply-To: <199509210455.GAA19796@foxbat.pix.za> from "Danie Brynard" at Sep 21, 
95 00:06:44 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1363 


For us Americans on-line, can someone translate :-) 
You know the joke, don't you ? 


What do you call someone who speaks three languages -- tri-lingual 
and someone who speaks two languages -- bi-lingual 


and someone who speaks one language ? 


Another dran American tourist. 


Cheers - greg 
According to Danie Brynard: 
Johan 


>Hoe genruik jy jou INT's op die com poorte? Is jy seker dat dit uniek is, 
>maw is daar nie ‘'n moontlikheid dat daar "device" drivers die interrupts 
>onderskep nie? Die lyk amper asof jy 'n mouse driver het wat die serie poort 
>data onderskep en dink jy beweeg die muis? Jy moet moontlik die mouse drywer 
>uithaal uit jou autoexec.? 


Ja jy is miskien reg ! Ek het vergeet van die device drivers wat daar sit en 
die int vektore verander, sal jou laat weet... 


>Nog ‘'n idee: hoe skakel jy die poorte om van DEBUG na SCI? Twee kabels na 
>die PC, of een kabel van die PC wat jy omruil op die EVM? 


VV VV VV VV VV VV VV VV 


Ek het twee kabels met db9's aan na com1 en com2. My debugger is op com2 en 
die SCI op com1. 


73 Danie 


PS O ja wou jou nog se; hulle is besig om 'n 64kbps lyn na ons mpy in te 
sit. Op die staduim het ek reeds Netcape @ 64kbps. Dis fantasties en wil nou 
bietjie ou Phil se .wav ens demo's aflaai op ‘'n dag. EK kan egter nog nie 
FTP en email nie. Dis nog nie ‘aangeskakel' nie. 


VVVVV VV VV VV WV 


From dibene@VNET.IBM.COM Thu Sep 21 09:58:07 1995 

Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by sys1.tapr.org 

(8.6.12/8.6.9) with SMTP id JAA30046 for <hfsig@tapr.org>; Thu, 21 Sep 1995 

09:58:00 -0500 

Message-Id: <199509211458. JAA30046@sys1.tapr.org> 

Received: from ROMVMNIC by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1871; 
Thu, 21 Sep 95 10:57:28 EDT 

Date: Thu, 21 Sep 95 16:20:15 GMT 

From: dibene@VNET.IBM.COM (Alberto di Bene) 

To: hfsig@tapr.org 

cc: KARN@QUALCOMM.COM 

Subject: Re: [HFSIG:607] Re: Pitch shifting 

Reply-To: dibene@VNET.IBM.COM 

Organization: IBM Semea S.p.A. 

News-Software: UReply 3.1 


In a previous message, you wrote: 

DS veces 

>Phasing-type SSB exciters fell by the wayside when crystal filters did 
>the job, because they required no careful adjustments. I predict phasing 
>will make a comeback now that you can do the job in DSP much better. 

De lect 


Thanks for the explanation Phil. Your prediction seems to be already 
true. Have you seen the new ICOM 775-DSP ? They claim SSB generation 
by mean of a DSP-controlled PSN (Phase Shift Network?) 


Alberto di Bene dibene@vnet.ibm.com i2phd@amsat.org 


From FORRERJ@frl.orst.edu Thu Sep 21 10:40:07 1995 

Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAA30907 for <hfsig@tapr.org>; Thu, 21 
Sep 1995 10:39:58 -0500 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAA13707 for <hfsig@tapr.org>; Thu, 21 Sep 1995 
08:40:10 -0700 

Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 


21 Sep 95 08:46:47 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 21 Sep 95 08:46:28 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 21 Sep 1995 08:46:22 PST8PDT 

Subject: Re: [HFSIG:609] Re: FCC regulations and multitone modems 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <445A6D254D@frl.orst.edu> 
Hi Phil, 


Although I admit that I have not seen the very latest regs, I assume that 
the rules/subbands for data transmission apply. The new regs apparently has 
500Hz bandwidth for unattended data transmission, also fully legalize 
Clover II and Pactor I (/II??). This implies that something has changed 
regarding the permissible code alphabets. The 500Hz bandwidth puzzles me a 
bit - so that means that the station that is in contact with the unattended 
station may be using a _different_ bandwidth - what does this help then to 
help with reducing interference as the new rule was intended for ? 


The only thing that I was wondering about is the 1 kHz shift issue. Without 
seeing the new regs, I am not sure how this applies to a multitone signal, 
hopefully Paul and Ian have looked at that. 


--Johan 


From karn@qualcomm.com Thu Sep 21 11:56:07 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id LAA32160 for <hfsig@tapr.org>; Thu, 21 
Sep 1995 11:56:01 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
JAA10171; Thu, 21 Sep 1995 09:55:52 -0700 

Date: Thu, 21 Sep 1995 09:55:52 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509211655.JAA10171@servo.qualcomm. com> 

To: dibene@VNET.IBM.COM 

CC: hfsig@tapr.org 

In-reply-to: <199509211457 .HAA11577@qualcomm.com> (dibene@VNET.IBM.COM) 
Subject: Re: [HFSIG:607] Re: Pitch shifting 


> Thanks for the explanation Phil. Your prediction seems to be already 
> true. Have you seen the new ICOM 775-DSP ? They claim SSB generation 
> by mean of a DSP-controlled PSN (Phase Shift Network?) 


I'd seen the ads, but had not read them closely. 


There are some other products on the market. A small company near here 
(Comer Communications) makes a PC plug-in card that when combined with 
a sound card and the right software produces a HF transceiver. The 
PC card is a direct conversion transceiver that produces quadrature 


baseband (I&Q) in a stereo jack for the sound card. The sound card can 
produce SSB by executing the Hilbert transform and adding or subtracting 
it from the untransformed data. Neat system. 


Phil 
From tomob@ix.netcom.com Thu Sep 21 12:25:06 1995 
Received: from ix9.ix.netcom.com (ix9.ix.netcom.com [199.182.120.9]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id MAA32755 for <hfsig@tapr.org>; Thu, 21 
Sep 1995 12:25:03 -0500 
Received: from by ix9.ix.netcom.com (8.6.12/SMI-4.1/Netcom) 
id KAA19191; Thu, 21 Sep 1995 10:24:49 -0700 
Date: Thu, 21 Sep 1995 10:24:49 -0700 
Message-Id: <199509211724 .KAA19191@1ix9.ix.netcom.com> 
From: tomob@ix.netcom.com (Thomas E. O'Boyle ) 
Subject: Re:FCC regulations and multitone modems 
To: hfsig@tapr.org 


Well that's great news from Chris and Paul on the approvals! 


I would be happy to run some tests with folks. Which EVM do I need? 
I'll get the units and wire up the board and the PTT cicuit. I'm 
assuming the program will us the DTR of the serial port for the 
function. 


I can spend about 1 to 2 hours early in the morning for testing. That 
might be a good time for Europe to test as well. 


Let me know how I can help! 
73 de Tom, N9IGUN 


From FORRERJ@frl.orst.edu Thu Sep 21 13:09:47 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id NAAQ0935 for <hfsig@tapr.org>; Thu, 21 
Sep 1995 13:09:42 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id LAA14798 for <hfsig@tapr.org>; Thu, 21 Sep 1995 
11:09:54 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

21 Sep 95 11:16:32 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 21 Sep 95 11:16:10 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 21 Sep 1995 11:16:03 PST8PDT 

Subject: Re: [HFSIG:615] Re:FCC regulations and multitone modems 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <46D9396609@frl.orst.edu> 
Hi Tom, 


We have the code running on the Motorola EVM, called the DSP56002EVM. It 


costs $150 and is available from most Motorola dealers. 
Get the software and interface schematic from: 
ftp.tapr.org/tapr/SIG/HFSIG/upload/evm56kic.zip 

Let me know of your progress and we can set up some skeds. 


--Johan 

From jbloom@usa.nai.net Thu Sep 21 13:16:04 1995 

Received: from usa.nai.net (usa.nai.net [204.71.21.10]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id NAAQ1062 for <hfsig@tapr.org>; Thu, 21 Sep 1995 
13:15:54 -0500 

Received: from jbloom.nai.net (jbloom.nai.net [204.71.21.17]) by usa.nai.net 
(8.6.5/8.6.5) with SMTP id 0AA15910 for <hfsig@tapr.org>; Thu, 21 Sep 1995 
14:12:37 -0400 

Message-Id: <199509211812 .0AA15910@usa.nai.net> 

Comments: Authenticated sender is <jbloom@usa.nai.net> 

From: "Jon Bloom" <jbloom@usa.nai.net> 

To: hfsig@tapr.org 

Date: Thu, 21 Sep 1995 14:15:42 -0400 

Subject: Re: [HFSIG:613] Re: FCC regulations and multitone modems 

Reply-to: jbloom@usa.nai.net 

Priority: normal 

X-mailer: Pegasus Mail for Windows (v2.10) 


Johan said: 

Although I admit that I have not seen the very latest regs, I assume that 
the rules/subbands for data transmission apply. The new regs apparently has 
500Hz bandwidth for unattended data transmission, also fully legalize 
Clover II and Pactor I (/II??). This implies that something has changed 
regarding the permissible code alphabets. The 500Hz bandwidth puzzles me a 
bit - so that means that the station that is in contact with the unattended 
station may be using a _different_ bandwidth - what does this help then to 
help with reducing interference as the new rule was intended for ? 


The only thing that I was wondering about is the 1 kHz shift issue. Without 
seeing the new regs, I am not sure how this applies to a multitone signal, 
hopefully Paul and Ian have looked at that. 


VV VV VV VV VV VV 


1) The 500-Hz bandwidth rule applies xonly*x to unattended stations 
operating outside the new "automatic" subbands. (And communication 
with these unattended stations can only be initiated by attended 
stations.) 


2) Automatic stations within that subband and attended stations, on 
any legal RTTY/data frequency, have xnox bandwidth restrictions. 
There is, however, a limit for FSK shift of "1 kHz between mark and 
space." (And when you have more than one "mark" and "space?" Hmmm...) 


The best way to answer any legality question is to first determine 
what emission mode the signal will be. (Like F1D, J2B, etc. Maybe 


this thing is D1D? I can never keep these things straight.) Once you 
know that, you're home free. 


That said, legal 3-kHz-wide signals in the CW/RTTY part of the more 
crowded HF bands will cause a lot of hate and discontent. I suggest 
restricting testing to the less crowded bands, at least at first. 


Coding isn't the issue. You can--and must, by regulation--transmit 
ASCII, ITA2 or CCIR-476 (AMTOR) codes over any data-transparent 
system, including Clover and Pactor. Don't confuse data coding with 
line coding/modulation techniques. They are two entirely different 
things. 


Bottom line is, if Paul and Chris say it's OK, you can pretty much 
take it to the bank. 


-- Jon 
Jon Bloom, KE3Z 
jbloom@nai.net 
From sadowskp@usafcrqs.nellis.af.mil Thu Sep 21 13:24:39 1995 
Received: from bncc.nellis.af.mil (bncc.nellis.af.mil [132.58.120.19]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id NAA01292 for <hfsig@tapr.org>; Thu, 21 
Sep 1995 13:24:13 -0500 
Received: from mailgtwy.nellis.af£f.mil by bncc.nellis.af.mil with SMTP 
(1.38.193.4/16.2) id AAQ0533; Thu, 21 Sep 1995 09:58:58 -0700 
Received: by mailgtwy.nellis.af.mil with Microsoft Mail 
id <306174FE@mailgtwy.nellis.af.mil>; Thu, 21 Sep 95 09:21:50 cdt 
From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af£.mil> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:608] FCC regulations and multitone modems 
Date: Thu, 21 Sep 95 09:05:00 cdt 
Message-Id: <306174FE@mailgtwy.nellis.af£.mil> 
Encoding: 43 TEXT 
X-Mailer: Microsoft Mail V3.0 


Johann 


Please tell me more about acquiring the Motorola EVM. We can take 
this to direct E-Mail... I would have responded that way but my E-Mail 
system doesn't keep the original sender of E-Mail postings on the SIG. 


Thanks in Advance 

Allan 

AH6LS 

sadowskp@usafcrqs.nellis.af.mil 

From: hfsig 

To: hfsig 

Subject: [HFSIG:608] FCC regulations and multitone modems 
Date: Wednesday, September 20, 1995 10:28AM 


Hi all, 


I did mention that we discussed the legal status of US amateur radio 
operator regarding the use of multitone modems on HF, at the recent DCC. 


I just heard from Chris Imlay, N3AKD in Washinton that he and Paul Rinaldo, 
the ARRL's liason with the FCC, checked the regulations and found no reason 
why we could not use our multitone modems on HF, except for unattended 
operations, where the restriction is now 500 Hz. 


This is good news. I take it from this good authority then that we can 
conduct our experiments on an international basis, something that would 
have been a problem with an STA. 


So, anyone interested in doing local trials for starters? All that is needed 


is a 386/486 computer running NOS, the Motorola EVM, a rather simple PTT 
interface, and appropiate cable to connect your transceiver to the EVM. 


73's 


--Johan, KC7WW 


From k4gvo@america.net Fri Sep 22 09:50:14 1995 

Received: from america.net (atl1.america.net [199.170.121.2]) by sys1.tapr.org 

(8.6.12/8.6.9) with ESMTP id JAA24100 for <hfsig@tapr.org>; Fri, 22 Sep 1995 

09:50:10 -0500 

Received: from k4gvo (pm1-25.america.net [199.170.121.124]) by america.net 

(8.6.10/8.6.9) with SMTP id OAAQ5979; Fri, 22 Sep 1995 14:47:39 GMT 

Message-Id: <199509221447 .O0AA05979@america.net> 

Sender: <k4gvo@atl1.america.net> 

From: "Jim Lynch" <k4gvo@america.net> 

To: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil>, 
hfsig@tapr.org 

Date: Fri, 22 Sep 1995 10:40:10 +0000 

Subject: Re: [HFSIG:618] RE: FCC regulations and multitone modems 

Reply-to: k4gvo@america.net 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.22) 


> Date: Thu, 21 Sep 1995 13:30:08 -0500 

> Reply-to: hfsig@tapr.org 

> From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil> 
> To: hfsig@tapr.org 

> Subject: [HFSIG:618] RE: FCC regulations and multitone modems 

> 

> Johann 

> 

> Please tell me more about acquiring the Motorola EVM. We can take 


> this to direct E-Mail... I would have responded that way but my E-Mail 
> system doesn't keep the original sender of E-Mail postings on the SIG. 
> 

> Thanks in Advance 

> Allan 

> AH6LS 

> sadowskp@usafcrqs.nellis.af.mil 

> wee eee eee = 


PLEASE don't take it private, ‘cause there are others of us 
interested too...... 


Jim. 
Jim Lynch Fayetteville, GA K4GV0O 
'86 GL1200I k4gvo@america.net 44.36.34.20 


From rick@itron-ca.com Fri Sep 22 11:36:39 1995 

Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by sys1.tapr.org 

(8.6.12/8.6.9) with ESMTP id LAA26075 for <hfsig@tapr.org>; Fri, 22 Sep 1995 

11:36:33 -0500 

Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id JAA24558 for 

<hfsig@tapr.org>; Fri, 22 Sep 1995 09:36:23 -0700 

Received: from unknown(204.30.20.118) by gate.itron-ca.com via smap (V1.3mjr) 
id sma024556; Fri Sep 22 09:35:30 1995 

Date: Fri, 22 Sep 95 09:30:36 PDT 

From: rick@itron-ca.com 

Subject: Motorola EVM 

To: hfsig@tapr.org 

X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. 

Message-ID: <Chameleon.4.01.950922093524.rick@rick.itron-ca.com> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Call 800-845-6686 with your mastercard/visa in hand and within a few days a 56002 
EVM 
will be at your doorstep. 


Rick w6nzk 


Rick Booth 
'95 900SS SP 
E-mail: rick@itron-ca.com 


From forrerj@ucs.orst.edu Fri Sep 22 12:03:52 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id MAA26593 for <hfsig@tapr.org>; Fri, 22 Sep 1995 
12:03:44 -0500 
Received: from p01.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AAQ6388; Fri, 22 Sep 1995 10:03:34 -0700 
Message-Id: <9509221703 .AAQ6388@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 


X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 22 Sep 1995 10:07:52 -0800 

To: hfsig@tapr.org 

From: forrerj@ucs.orst.edu (Johan Forrer) 

Subject: Re: [HFSIG:619] RE: FCC regulations and multitone modems 


Hi Jim, 

>> Date: Thu, 21 Sep 1995 13:30:08 -0500 
>> Reply-to: hfsig@tapr.org 

>> From: "Sadowski,P CPT USAF CRQS/RQEN" 
<sadowskp@usafcrqs.nellis.af.mil> 

>> To: hfsig@tapr.org 

>> Subject: [HFSIG:618] RE: FCC regulations and multitone modems 
> 

>> 

>> Johann 

>> 


>> Please tell me more about acquiring the Motorola EVM. We can take 
>> this to direct E-Mail... I would have responded that way but my E-Mail 
>> system doesn't keep the original sender of E-Mail postings on the SIG. 


>> Thanks in Advance 

>> Allan 

>> AH6LS 

>> sadowskp@usafcrqs.nellis.af.mil 

>> wore renee 

>PLEASE don't take it private, ‘cause there are others of us 
>interested too...... 


> 

>Jim. 

>Jim Lynch Fayetteville, GA K4GV0O 

>'86 GL1200I k4gvo@america.net 44 .36.34.20 
> 


We will try and accomodate all that may be interested. 


There obviously are those that are willing and capable to help themselves. I 
have no doubt that those that are capable will be up and running shortly, so 
we have to do something to help those that need further help to get going. 


We can perhaps talk TAPR into arranging for PCB's to be made and a parts kit 
put together. This would be low cost/low parts count. What do you think of 
the prospect Greg? 


--Johan 


From GARRETIJ2@btlip15.bt.co.uk Fri Sep 22 12:44:06 1995 

Received: from zaphod.axion.bt.co.uk (zaphod.axion.bt.co.uk [132.146.5.1]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id MAA27126 for <HFSIG@TAPR.ORG>; Fri, 22 
Sep 1995 12:44:02 -0500 


Received: from smtpgate.comnet.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); 
Fri, 22 Sep 1995 18:43:26 +0100 

Received: by smtpgate.comnet.bt.co.uk with Microsoft Mail id 
<3062F689@smtpgate.comnet.bt.co.uk>; Fri, 22 Sep 95 18:46:49 BST 
From: "Garrett, John, GARRETI2" <GARRETJ2@bt1ip15.bt.co.uk> 

To: HFSIG@TAPR.ORG 

Subject: [HFSIG:605] HFSIG at DCC 

Date: Thu, 21 Sep 95 09:15:00 BST 

Message-ID: <3062F689@smtpgate.comnet.bt.co.uk> 

Encoding: 2 TEXT 

X-Mailer: Microsoft Mail V3.0 


Away until 25th September. Please contact Lynn Dunnett on 01473 644859 for 
assistance in my absence. 

From gjones@tenet.edu Fri Sep 22 14:31:28 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 
by sysi.tapr.org (8.6.12/8.6.9) with ESMTP id OAA28939 for <hfsig@tapr.org>; Fri, 
22 Sep 1995 14:31:23 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 
OAA09387 for hfsig@tapr.org; Fri, 22 Sep 1995 14:31:33 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199509221931.0AA09387@Leslie-Francis.tenet.edu> 

Subject: Re: [HFSIG:621] RE: FCC regulations and multitone modems 

To: hfsig@tapr.org 

Date: Fri, 22 Sep 1995 14:31:33 -0500 (CDT) 

In-Reply-To: <9509221703.AA06388@ucs.orst.edu> from "Johan Forrer" at Sep 22, 95 
12:13:19 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1274 


According to Johan Forrer: 
> We will try and accomodate all that may be interested. 


> 

> There obviously are those that are willing and capable to help themselves. I 
> have no doubt that those that are capable will be up and running shortly, so 
> we have to do something to help those that need further help to get going. 

> 

> We can perhaps talk TAPR into arranging for PCB's to be made and a parts kit 
> put together. This would be low cost/low parts count. What do you think of 

> the prospect Greg? 

> 


Not sure if everyone understands what is being disscussed here. Basically 
it is an interface board to the EVM. 


I have someone who approached us about doing some PCB layout...so would be a 
good opportunity to test him out...if we can design it so that parts can be 
purchased at Radio Shack or DigikKey (since the parts count is low) then we 
could a PCB turn only...and not have to worry about parts -- which is the 
most time consuming aspect. 


How many people are interested ? I guess we should some how get a count. 


Poeple should e-mail someone (who wants to volunteer) to keep a quick count. 


...0r might think about going to an 
outside source and having something made. All depends on the cost and what 
people want to purchase. 


Sounds like a good idea. 


Greg 

From forrerj@ucs.orst.edu Fri Sep 22 19:09:44 1995 

Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id TAAQ1852 for <hfsig@tapr.org>; Fri, 22 Sep 1995 
19:09:40 -0500 


Received: from p01.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA17457; Fri, 22 Sep 1995 17:09:29 -0700 
Message-Id: <9509230009.AA17457@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 22 Sep 1995 17:13:49 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: First call for EVM interface PCB 


Hi Greg, 

>Not sure if everyone understands what is being discussed here. Basically 
>it is an interface board to the EVM. 

I changed the subject title a bit. 

> 

>I have someone who approached us about doing some PCB layout...so would be a 


>good opportunity to test him out...if we can design it so that parts can be 
>purchased at Radio Shack or Digikey (since the parts count is low) then we 


>could a PCB turn only...and not have to worry about parts -- which is the 
>most time consuming aspect. 
> 


Danie, ZS6AWK, being an EE, has done a rather pretty PCB for his EVM. I 
think he would be quite willing to contribute his work - OK Danie? People 
should just be aware that more involved interfaces may be developed in the 
near future, so things are not cast in concrete. The unit that I had at the 
DCC has more than what is needed for our proposed tests. Note there NO 
modifications required on the EVM itself. 


>How many people are interested ? I guess we should some how get a count. 
>People should e-mail someone (who wants to volunteer) to keep a quick count. 


This is important to know before we go on. I'll be happy to take a count. 
Thanks, 

--Johan, KC7WW 

e-mail: forrerj@ucs.orst.edu 


From gjones@tenet.edu Fri Sep 22 21:01:35 1995 

Received: from Joyce-Perkins.tenet.edu (Joyce-Perkins.tenet.edu [198.213.2.6]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id VAAQ3680 for <hfsig@tapr.org>; Fri, 22 
Sep 1995 21:01:32 -0500 

Received: (from gjones@localhost) by Joyce-Perkins.tenet.edu (8.6.12/8.6.12) id 
VAA17467 for hfsig@tapr.org; Fri, 22 Sep 1995 21:01:28 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199509230201.VAA17467@Joyce-Perkins.tenet.edu> 

Subject: Re: [HFSIG:624] First call for EVM interface PCB 

To: hfsig@tapr.org 

Date: Fri, 22 Sep 1995 21:01:28 -0500 (CDT) 

In-Reply-To: <9509230009.AA17457@ucs.orst.edu> from "Johan Forrer" at Sep 22, 95 
07:23:10 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1694 


Let's take a count. Talk to Danie about getting board layout files and go 
from there. 


Basically the NRE on a board run will be $250 (give or take) plus $50 or so 
for any photoplotting that would have to be done. 


It takes between two and three weeks for a turn...once everything is ready. 


Just a matter of finding out how many to run. The size of run effects the 
per-board cost. 


Greg 

According to Johan Forrer: 

Hi Greg, 

>Not sure if everyone understands what is being discussed here. Basically 
>it is an interface board to the EVM. 

I changed the subject title a bit. 

> 

>I have someone who approached us about doing some PCB layout...so would be a 


>good opportunity to test him out...if we can design it so that parts can be 
>purchased at Radio Shack or Digikey (since the parts count is low) then we 
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>could a PCB turn only...and not have to worry about parts -- which is the 
>most time consuming aspect. 
> 


Danie, ZS6AWK, being an EE, has done a rather pretty PCB for his EVM. I 
think he would be quite willing to contribute his work - OK Danie? People 
should just be aware that more involved interfaces may be developed in the 
near future, so things are not cast in concrete. The unit that I had at the 
DCC has more than what is needed for our proposed tests. Note there NO 
modifications required on the EVM itself. 


>How many people are interested ? I guess we should some how get a count. 
>People should e-mail someone (who wants to volunteer) to keep a quick count. 
This is important to know before we go on. I'll be happy to take a count. 
Thanks, 

--Johan, KC7WW 


e-mail: forrerj@ucs.orst.edu 


VVVVV VV VV VV VV VV VV VM VV VV VV 


From emblidge@ns.moran.com Fri Sep 22 21:31:09 1995 

Received: from ns.moran.com (ns.moran.com [204.97.213.2]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id VAAQ4482 for <hfsig@tapr.org>; Fri, 22 Sep 1995 
21:30:45 -0500 

Received: from emblidge.moran.com (nw36.moran.com [204.97.213.36]) by ns.moran.com 
(8.6.12/8.6.9) with SMTP id WAAQ7544 for <hfsig@tapr.org>; Fri, 22 Sep 1995 
22:49:43 -0400 

Date: Fri, 22 Sep 95 22:31:04 PDT 

From: "Daniel R. Emblidge" <emblidge@ns.moran.com> 

Subject: cancel 

To: hfsig@tapr.org 

X-Mailer: Chameleon VO.05, TCP/IP for Windows, NetManage Inc. 

Message-ID: <Chameleon.950922223120.emblidge@emblidge.moran.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Name: Daniel R. Emblidge 

E-mail: emblidge@moran.com (Daniel R. Emblidge) 
Date: 09/22/95 

Time: 22:31:04 


This message was sent by Chameleon 4.5 


From faunt@netcom.com Fri Sep 22 22:10:50 1995 


Received: from netcom9.netcom.com (netcom9.netcom.com [192.100.81.119]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id WAAQ5399 for <hfsig@tapr.org>; Fri, 22 
Sep 1995 22:10:44 -0500 
Received: by netcom9.netcom.com (8.6.12/Netcom) 
id UAA14058; Fri, 22 Sep 1995 20:07:32 -0700 
Date: Fri, 22 Sep 1995 20:07:32 -0700 
From: faunt@netcom.com (Doug Faunt N6TQS +1-510-655-8604) 
Message-Id: <199509230307 .UAA14058@netcom9.netcom. com> 
To: hfsig@tapr.org 
In-reply-to: <199509230201.VAA17467@Joyce-Perkins.tenet.edu> (gjones@tenet.edu) 
Subject: Re: [HFSIG:625] Re: First call for EVM interface PCB 


Apparently I have volunteered to take a count of people interested in 


this board. Send mail to me, faunt@netcom.com, if you're interested 
in purchasing a PC board for the interface for the EVM. 


Date: Fri, 22 Sep 1995 21:04:01 -0500 
Originator: hfsig@tapr.org 


Let's take a count. Talk to Danie about getting board layout files and go 
from there. 


Basically the NRE on a board run will be $250 (give or take) plus $50 or so 
for any photoplotting that would have to be done. 


It takes between two and three weeks for a turn...once everything is ready. 


Just a matter of finding out how many to run. The size of run effects the 
per-board cost. 


Greg 


According to Johan Forrer: 


> 

> Hi Greg, 

> 

> 

> >Not sure if everyone understands what is being discussed here. Basically 

> >it is an interface board to the EVM. 

> 

> I changed the subject title a bit. 

> 

>> 

> >I have someone who approached us about doing some PCB layout...so would be a 
> >good opportunity to test him out...if we can design it so that parts can be 
> >purchased at Radio Shack or Digikey (since the parts count is low) then we 
> >could a PCB turn only...and not have to worry about parts -- which is the 

> >most time consuming aspect. 

>> 

> 

> Danie, ZS6AWK, being an EE, has done a rather pretty PCB for his EVM. I 

> think he would be quite willing to contribute his work - OK Danie? People 


should just be aware that more involved interfaces may be developed in the 
near future, so things are not cast in concrete. The unit that I had at the 
DCC has more than what is needed for our proposed tests. Note there NO 
modifications required on the EVM itself. 


>How many people are interested ? I guess we should some how get a count. 
>People should e-mail someone (who wants to volunteer) to keep a quick count. 


This is important to know before we go on. I'll be happy to take a count. 


Thanks, 
--Johan, KC7WW 


e-mail: forrerj@ucs.orst.edu 
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From sadowskp@usafcrqs.nellis.af.mil Mon Sep 25 14:43:49 1995 
Received: from bncc.nellis.af.mil (bncc.nellis.af.mil [132.58.120.19]) by 


sysi.tapr.org (8.6.12/8.6.9) with SMTP id OAA10893 for <hfsig@tapr.org>; Mon, 25 


Sep 1995 14:43:40 -0500 
Received: from mailgtwy.nellis.af£f.mil by bncc.nellis.af.mil with SMTP 
(1.38.193.4/16.2) id AAQ7574; Mon, 25 Sep 1995 12:25:21 -0700 
Received: by mailgtwy.nellis.af.mil with Microsoft Mail 
id <3066DA08@mailgtwy.nellis.af.mil>; Mon, 25 Sep 95 11:34:16 cdt 
From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:625] Re: First call for EVM interface PCB 
Date: Mon, 25 Sep 95 11:45:00 cdt 
Message-Id: <3066DAQ8@mailgtwy.nellis.af.mil> 
Encoding: 42 TEXT 
X-Mailer: Microsoft Mail V3.0 


Question about the layout.... does he use "skinny" traves out to Vcc and Vdd 
or does he leave most of the board metal alone and just removes metal for 
signal isolation.. also is it single sided or dual sided? hmmm oh... what 


all is on "his" PCB... I got the impression that his PCB included the EVM 
circuitry in addition to the interface circuits.. I'm looking forward to 
more info... 


I am interested... particularly if it's a quality board that fits ina 
readily available box, the parts are from digikey or Radio shack, and it's 
expandable.. 


some folks just want everything... hahahaha 
Thanks in advance 


Allan 
AH6LS 


sadowskp@usafcrqs.nellis.af.mil 

From: hfsig 

To: hfsig 

Subject: [HFSIG:625] Re: First call for EVM interface PCB 
Date: Friday, September 22, 1995 9:02PM 


Let's take a count. Talk to Danie about getting board layout files and go 
from there. 


> >purchased at Radio Shack or Digikey (since the parts count is low) then 
we 


>could a PCB turn only...and not have to worry about parts -- which is the 
>most time consuming aspect. 
> 


Danie, ZS6AWK, being an EE, has done a rather pretty PCB for his EVM. I 
think he would be quite willing to contribute his work - OK Danie? People 
should just be aware that more involved interfaces may be developed in the 
near future, so things are not cast in concrete. The unit that I had at 
the 
> DCC has more than what is needed for our proposed tests. Note there NO 
> modifications required on the EVM itself. 
> 
From FORRERJ@frl.orst.edu Mon Sep 25 16:01:56 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id QAA12791 for <hfsig@tapr.org>; Mon, 25 
Sep 1995 16:01:44 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id OAAQ1720 for <hfsig@tapr.org>; Mon, 25 Sep 1995 
14:01:54 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

25 Sep 95 14:08:20 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 25 Sep 95 14:08:15 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


VVVVVV VV 


Date: Mon, 25 Sep 1995 14:08:13 PST8PDT 

Subject: Re: [HFSIG:628] Re: First call for EVM interface PCB 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <A9BA451340@frl.orst.edu> 
Allan, 


The interface is really simple: three transistor (or FET) switches for PTT, 
Up and Down. Two LED's (Green=heartbeat, Red=DCD). In addition I have 
adjustable audio attenuators to get at the audio levels. Then I also 

added a DIN socket on the chassis to carry the PTT and audio in/out signals. 
It may be a good idea to keep the connector wired in such a way that it is 
interchangeable with your 1200/9600 baud VHF setup, just in case you want 
to use it on those circuits (we won't get VHF issues here on HFSIG). 


As far as you can see then, there is no need for special high speed 
digital considerations. 


I still need to get in touch with Danie and see if we can make it the same 
size as the EVM, with the headers aligned so that the interface plugs into 
the EVM to form a mother/daughterboard pair with a footprint the size of 

the EVM. I do not think there is much to the layout, probably a single-sided 
board that you can even make using the "photocopy and iron" process to make 
a direct etch board, that is, if you want to try it yourself. 


--Johan 
From k4gvo@america.net Tue Sep 26 04:30:07 1995 


Received: from america.net (atl1.america.net [199.170.121.2]) by sys1.tapr.org 


(8.6.12/8.6.9) with ESMTP id EAA31810 for <hfsig@tapr.org>; Tue, 26 Sep 1995 
04:30:03 -0500 

Received: from k4gvo (pm1-23.america.net [199.170.121.122]) by america.net 
(8.6.10/8.6.9) with SMTP id JAAQ1056 for <hfsig@tapr.org>; Tue, 26 Sep 1995 
09:27:38 GMT 

Message-Id: <199509260927 .JAAQ1056@america.net> 

Sender: <k4gvo@atl1.america.net> 

From: "Jim Lynch" <k4gvo@america.net> 

To: hfsig@tapr.org 

Date: Tue, 26 Sep 1995 05:19:31 +0000 

Subject: Re: [HFSIG:621] RE: FCC regulations and multitone modems 
Reply-to: k4gvo@america.net 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.22) 


> Date: Fri, 22 Sep 1995 12:13:06 -0500 

> Reply-to: hfsig@tapr.org 

> From: forrerj@ucs.orst.edu (Johan Forrer) 

> To: hfsig@tapr.org 

> Subject: [HFSIG:621] RE: FCC regulations and multitone modems 
> Hi Jim, 

> 

Hi, Johan.. 

> >PLEASE don't take it private, ‘cause there are others of us 


>interested too...... 


Vv 


We will try and accomodate all that may be interested. 

There obviously are those that are willing and capable to help themselves. 
we have to do something to help those that need further help to get going. 
put together. This would be low cost/low parts count. What do you think of 
the prospect Greg? 


--Johan 


VV VV VV VV VV VV OV 


I 


have no doubt that those that are capable will be up and running shortly, so 


We can perhaps talk TAPR into arranging for PCB's to be made and a parts kit 


Johan, 


Help me here. Doesn't the EVM come on a board? How much extra 
circuitry is needed to make it play? Guess I'll have to order one 
and see..8%) Were you suggesing that this PCB is a duplicate of the 
EVM (if it has one) or an enhanced one? 


Thanks, 

Jim. 

> 

Jim Lynch Fayetteville, GA K4GV0O 

'86 GL1200I k4gvo@america.net 44.36.34.20 


From jalocha@vxcern.cern.ch Tue Sep 26 08:13:17 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id IAAQ3907 for <hfsig@tapr.org>; Tue, 26 Sep 1995 
08:13:05 -0500 
Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch 
id AA22171; Tue, 26 Sep 1995 14:12:49 +0100 
Date: Tue, 26 Sep 1995 14:12:49 +0100 
Message-Id: <9509261312.AA22171@dxmint.cern.ch> 
From: jalocha@vxcern.cern.ch (Pawel Jalocha) 
X-Vms-To: MINT"hfsig@tapr.ors" 
Subject: Making the EVM56K play 
X-Mail11-Ostype: VAX/VMS 
Apparently-To: <hfsig@tapr.org> 


Just to explain certain facts about the EVM56K. 
In principle, you DO NOT NEED ANY EXTRA CIRCUITY to make the EVM56K 
"play". When you get the bare board from Motorola, after you get familiar 


with their interface software you proceed this way: 


- set the EVM56K's to 16K RAM configuration (one jumper to be moved). 
- start the EVM56K.EXE and type: 


load bios.cld (load Johan's BIOS which makes EVM56K look like DSPCARD4) 
load fft-cut.cld (load Pawel's noise filter - or any other application) 
go 0 (start the BIOS which then starts the application) 


Your EVM56K is playing already ! Pure software you see :-) 
Put headphones in the HEAD sockets and some noisy audio into MIC 
socket and you are in the tricky business of anti-noise filters. 


Now, if you with to work packet, you need to solder (*) the second 

RS232 socket onto the EVM56K and then yuo need to move two jumpers 

and add another two. After you have done that, you can run the 1200 bps 
modem or the multi-tone modem and communicate with it in the KISS protocol. 
You stick the TRX audio into MIC socket, the OUT socket you put into 

MIC of the TRX (put an attenuator here) and here we go ! 

Well, you are still missing the PTT signal but after all why not 

to use VOX ? :-) 


If you want the PTT line you need to take one of the lines 


available on the numerous EVM56K's sockets, add a transistor, 
a resistor maybe and a protective Zener diode. You have 
a proper PTT now for the TRX. 


And if you want a full blown radio interface with some other 
usefull stuff then think about the Johan/Danie's board. 
But you DO NOT NEED ANY EXTRA CIRCUITY to make the EVM56K play ! 


Pawel 


(*) While your soldering iron is still hot, put on the extra 

28-pin IC socket for the (E)EPROM. 
From FORRERJ@frl.orst.edu Tue Sep 26 10:39:01 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ7820 for <hfsig@tapr.org>; Tue, 26 
Sep 1995 10:38:56 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAAQ5969 for <hfsig@tapr.org>; Tue, 26 Sep 1995 
08:39:01 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

26 Sep 95 08:45:28 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 26 Sep 95 08:45:25 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 26 Sep 1995 08:45:19 PST8PDT 

Subject: Re: [HFSIG:630] RE: FCC regulations and multitone modems 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <BC59646B5F@frl.orst.edu> 
Hi Jim, 


Let me briefly repeat what is in the QEX November 1995 article on the EVM: 
The EVM, or its real name: DSP56002EVM, is made by Motorola DSP division. 
It is intended as a low cost evaluation module and is a complete DSP system 
on small PCB, some 2.4 x 4 inches or so. The PCB contains a 40 MHz (20 
MIPs) 56002 DSP, 32K x 24 SRAM, and a Crystal Semi CS4215 CODEC. In 
addition, the unit has an optional socket for a FLASH Prom. The unit hooks 
up to a PC's serial port at 19.2K. It is possible to load your own DSP 

code via the debugger, however, once debugged, one can (using supplied 
code) transfer the code to the FLASH Eprom and operate the unit as a 
free-standing application. This is how we intend operating the modem. 


Now, to be able to use the modem, you will need some additional hardware to 
convert some TTL levels, i.e., pull in a PTT relay. In addition, you also 
need to scale audio levels to suit your particular tansceiver. This is 

the only and all the hardware that we are talking about. To enable such 
interfaces to be built, the EVM provides for a couple of headers (rows 

of pins) that allows access to the DSP's I/O pins. The interface board is 
thus made such that one can plug it into these headers, just like a 
disconnect header on a TNC. 


Hopefully it is clear now that the interface board is a very sparsely 
populated board, with only a few transistors, diodes, capacitors, LED's and 
trimpots. The EVM itself is complete already with all the digital 

and analog circuitry to run the modem application. 


Hope this helps. 


--Johan 

From gjones@tenet.edu Tue Sep 26 16:41:45 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 
by sysi.tapr.org (8.6.12/8.6.9) with ESMTP id QAA17278 for <hfsig@tapr.org>; Tue, 
26 Sep 1995 16:41:40 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 
QAA28141 for hfsig@tapr.org; Tue, 26 Sep 1995 16:41:30 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199509262141.QAA28141@Leslie-Francis.tenet.edu> 

Subject: Re: [HFSIG:632] RE: FCC regulations and multitone modems 

To: hfsig@tapr.org 

Date: Tue, 26 Sep 1995 16:41:30 -0500 (CDT) 

In-Reply-To: <BC59646B5F@frl.orst.edu> from "Johan Forrer" at Sep 26, 95 11:13:28 
am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1915 


Good overview Johan. 


The board we are tlkaing about doing would be a one sided, maybe two sided 
board that woudl just make it easier and more stable (mechanical wise) to 
mount these parts, instead of bread-boarding the parts. 


Cheers - Greg 
According to Johan Forrer: 
Hi Jim, 


Let me briefly repeat what is in the QEX November 1995 article on the EVM: 
The EVM, or its real name: DSP56002EVM, is made by Motorola DSP division. 
It is intended as a low cost evaluation module and is a complete DSP system 
on small PCB, some 2.4 x 4 inches or so. The PCB contains a 40 MHz (20 
MIPs) 56002 DSP, 32K x 24 SRAM, and a Crystal Semi CS4215 CODEC. In 
addition, the unit has an optional socket for a FLASH Prom. The unit hooks 
up to a PC's serial port at 19.2K. It is possible to load your own DSP 

code via the debugger, however, once debugged, one can (using supplied 
code) transfer the code to the FLASH Eprom and operate the unit as a 
free-standing application. This is how we intend operating the modem. 


Now, to be able to use the modem, you will need some additional hardware to 
convert some TTL levels, i.e., pull in a PTT relay. In addition, you also 
need to scale audio levels to suit your particular tansceiver. This is 
the only and all the hardware that we are talking about. To enable such 
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interfaces to be built, the EVM provides for a couple of headers (rows 

of pins) that allows access to the DSP's I/O pins. The interface board is 
thus made such that one can plug it into these headers, just like a 
disconnect header on a TNC. 


Hopefully it is clear now that the interface board is a very sparsely 
populated board, with only a few transistors, diodes, capacitors, LED's and 
trimpots. The EVM itself is complete already with all the digital 

and analog circuitry to run the modem application. 


Hope this helps. 


--Johan 
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From k4gvo@america.net Wed Sep 27 04:42:26 1995 

Received: from america.net (atl1.america.net [199.170.121.2]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id EAAQ3709 for <hfsig@tapr.org>; Wed, 27 Sep 1995 
04:42:22 -0500 

Received: from k4gvo (pm1-25.america.net [199.170.121.124]) by america.net 
(8.6.10/8.6.9) with SMTP id JAAQ5062 for <hfsig@tapr.org>; Wed, 27 Sep 1995 
09:39:56 GMT 

Message-Id: <199509270939. JAAQ5062@america.net> 

Sender: <k4gvo@atl1.america.net> 

From: "Jim Lynch" <k4gvo@america.net> 

To: hfsig@tapr.org 

Date: Wed, 27 Sep 1995 05:42:09 +0000 

Subject: Re: [HFSIG:633] RE: FCC regulations and multitone modems 
Reply-to: k4gvo@america.net 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.22) 


> > Hi Jim, 

> 

(snip) 

> > Hope this helps. 
SS 

> > --Johan 


It did, thank you very much. I'll be ordering one today... 


Jim. 
Jim Lynch Fayetteville, GA K4GV0O 
'86 GL1200I k4gvo@america.net 44.36.34.20 


From danie.brynard@pixie.co.za Thu Sep 28 07:44:21 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id HAAQ1656 for <hfsig@tapr.org>; Thu, 28 Sep 1995 
07:44:06 -0500 

Received: from net-5.pta.pix.za ([196.11.63.141]) by foxbat.pix.za (8.6.12/8.6.12) 
with SMTP id GAA28629 for <hfsig@tapr.org>; Thu, 28 Sep 1995 06:09:50 +0200 

Date: Thu, 28 Sep 1995 06:09:50 +0200 

Message-Id: <199509280409.GAA28629@foxbat.pix.za> 


X-Sender: pakO03226@pixie.co.za (Unverified) 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 
Subject: Re: [HFSIG:614] Re: Pitch shifting 


>There are some other products on the market. A small company near here 
>(Comer Communications) makes a PC plug-in card that when combined with 
>a sound card and the right software produces a HF transceiver. The 

>PC card is a direct conversion transceiver that produces quadrature 
>baseband (I1&Q) in a stereo jack for the sound card. The sound card can 
>produce SSB by executing the Hilbert transform and adding or subtracting 
>it from the untransformed data. Neat system. 

> 

>Phil 

> 

> 


Phil do you perhaps have a fax or email number for the company. I am 
interested and want to get more info. 


Danie ZS6AWK 


From gwyn@paccomm.com Thu Sep 28 08:43:04 1995 

Received: from paccomm.com ([163.125.30.1]) by sysi.tapr.org (8.6.12/8.6.9) with 

SMTP id IAAQ3324 for <hfsig@tapr.org>; Thu, 28 Sep 1995 08:42:47 -0500 

X-BBS-Msg-Type: P 

Date: Thu, 28 Sep 95 09:28:19 UTC 

Message-Id: <6691@paccomm. com> 

From: gwyn@paccomm.com (Gwyn Reedy, W1BEL) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:635] Re: Pitch shifting 

In-Reply-To: your message of Thu, 28 Sep 1995 08:11:03 -0500. 
<6689@paccomm. com> 


Comer Communications, Inc. 
Brian D. Comer, President 
609 Washingtonia Drive 
San Marcos, CA 92069 


(619) 744-7266 
fax (619) 744-4745 
Radware BBS (619) 744-4032 


Gwyn Reedy, WIBEL —— gwyn@paccomm.com = ~—s WIBEL@amsat.org tits 
+(813) 874-2980 Fax:+(813) 872-8696 BBS: +(813) 874-3078 (V.34) 


PacComm Packet Radio Systems, Inc, 4413 N. Hesperides St, Tampa, FL 33614-7618 
From forrerj@ucs.orst.edu Thu Sep 28 10:56:04 1995 


Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id KAAQ6385 for <HFSIG@tapr.org>; Thu, 28 Sep 1995 
10:56:00 -0500 
Received: from p03.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA22313; Thu, 28 Sep 1995 08:55:49 -0700 
Message-Id: <9509281555 .AA22313@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 28 Sep 1995 09:00:33 -0800 
To: HFSIG@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: EVM interface PCB layout 


Hi, 


I am in the process of finishing op the PCB layout and will post it on the 
HFSIG upload area. Look for it by the end of the weekend (EVMPCBO.ZIP). This 
will be revision 0 (Rev.0), so I would appreciate feedback so we can 
finalize the layout. 


--Johan, KC7WW 


From karn@qualcomm.com Thu Sep 28 18:10:39 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id SAA15836 for <hfsig@tapr.org>; Thu, 28 
Sep 1995 18:10:33 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
PAA20766; Thu, 28 Sep 1995 15:17:20 -0700 

Date: Thu, 28 Sep 1995 15:17:20 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509282217 .PAA20766@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <6691@paccomm.com> (gwyn@paccomm.com) 

Subject: Comments on Radware HF XCVR card 


I bought one of these last spring, but it sat on my shelf until 
recently when I made some time to play with it. 


The card does work, but I am not overly impressed with its RX 
performance. It uses a direct conversion design, and as I feared it 
suffers from several of its inherent drawbacks. 


First of all, I should say that there's xonex traditional DC drawback 
it does not suffer from: it can receive just one sideband. That's 
because it produces a complex (I&Q) output, and a Hilbert transformer 
running in the DSP sound card completes a "phasing type" 

receiver. This part seems to work well. The DSP filters are clearly 
better than anything you can get out of a passive crystal filter. 


But the board does suffer from another classic drawback of direct 
conversion: noise. Direct conversion receivers generally have lots of 
baseband gain, which makes them highly susceptible to audio frequency 
noise. The Radware card is encased in a hefty metal shield, but it's 
not perfect. It still gets lots of noise from other parts of my 
computer. (I've not noticed any microphonics, however, probably 
because the VCO is a digitally controlled DDS/PLL/divider chain, not a 
conventional VFO with airgap tuning capacitors that make good 
capacitor microphones). 


A dual fan card in my system induced a loud whine in the audio output. 
Although removing this card dropped the noise level considerably, it 
still picked up lesser amounts of noise from elsewhere in the system: 
the power supply fan, hard disk (you can hear the heads moving!) and 
the CPU itself (you hear the activity from the 18.2 Hz clock tick). 


And if the audio gain is too high, you get feedback. And near the 
feedback point you get an reverberation-like effect. The echo delays 
are large enough to make me suspect coupling from the audio amplifier 
on the sound card through the power supply and into the RX board. 
(The delay is relevant because it indicates that the DSP filters are 
in the path). The feedback was definitely not accoustic -- it still 
occurred at the same gain level with headphones. 


I put a Mini Circuits Labs broadband preamp (20-30dB gain) in front of 
the receiver. The extra gain pretty much solved the noise problem (the 
system now became external noise limited) but at the expense of 
significantly increased intermod. The specified IP3 of the receiver is 
only +16dBm, and this isn't enough with 20-30dB of extra RF gain to 
really resist strong shortwave broadcast stations. You could hear them 
leaking through the baseband path whenever you were tuned within about 
10-15 KHz on either side (ie., within the anti-alias filters before 
the A/D converters.) 


It's a shame, because I really think this is the future of radio 

design and I would really like to see this card (and the company that 
designed it) succeed. But it just can't compete with my IC-751A, at least 
not yet. 


Phil 
From forrerj@ucs.orst.edu Fri Sep 29 19:48:37 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id TAA20899 for <hfsig@tapr.org>; Fri, 29 Sep 1995 
19:48:29 -0500 
Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA17968; Fri, 29 Sep 1995 17:48:22 -0700 
Message-Id: <9509300048.AA17968@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 29 Sep 1995 17:53:09 -0800 


To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: PCB for EVM-based HF modem 


Hi, 


I uploaded revision 0 of the PCB for the EVM to 
ftp.tapr.org/tapr/SIG/hfsig/upload.evmpcb.zip 


The package contains a couple of HPGL plot files for the schematic and PCB 
layout. Please look over the material and let me have your comments as soon 
as possible. 


For those that are familiar with locating parts: we need three headers to 
interconnect the boards. They have to be about 1/2 inch high for use with 
suare posts. I have some in my junk box but don't know where to locate these 
at short notice. Could someone please help with information on these items. 


I followed the format as used for the DSP-93 for the transceiver to EVM 
connector. This is a 8-pin mini DIN. 


Hope this gets you started. 
73's 
--Johan, KC7WW 


From s5éa@ljutcp.hamradio.si Sat Sep 30 01:17:08 1995 
Received: from ljutcp.hamradio.si (radio.kud-fp.si [193.2.132.80]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id BAA28447 for <hfsig@tapr.org>; Sat, 30 
Sep 1995 01:17:04 -0500 
Date: Sat, 30 Sep 95 06:07:02 UTC 
Message-Id: <86827@ljutcp.hamradio.si> 
From: Marijan Miletic <s56a@ljutcp.hamradio.si> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:638] Comments on Radware HF XCVR card 
In-Reply-To: your message of Thu Sep 28 18:24:27 1995 
<199509282217 .PAA20766@servo.qualcomm. com> 


It is so nice to read a qualified report on Radware XCVR with DC RX 
performances as expected! However, +16 dBm IMD is much better than 

2.700$ new Kenwood DSP box with TS-870 label. Only 2/12 dBm was measured at 
12.5 kHz spacing. There was PC plug-in RX for 0.5-1300 MHz on display at DL 
hamfest made by Rosseta labs. from VK. It had no antenna attached but fancy 
Windows interface was advertised. Good old IC-751A is not easy to beat thanks 
to his front end PIN AGC attenuator and decent low noise VCO... 


73 de Mario, S56A, N1YU. 


P.S. It is nice to see some "analog" discussion here for a change :-) 

From jalocha@vxcern.cern.ch Sat Sep 30 14:17:53 1995 

Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id OAA10055 for <hfsig@tapr.org>; Sat, 30 Sep 1995 


14:17:49 -0500 

Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch 
id AA25933; Sat, 30 Sep 1995 20:17:46 +0100 

Date: Sat, 30 Sep 1995 20:17:46 +0100 

Message-Id: <9509301917 .AA25933@dxmint.cern.ch> 

From: jalocha@vxcern.cern.ch (Pawel Jalocha) 

X-Vms-To: MINT"hfsig@tapr.ors" 

Subject: EVM56K's supply 

X-Mail1i1-Ostype: VAX/VMS 

Apparently-To: <hfsig@tapr.org> 


The EVM56K has a little imperfection around its supply. 

The circuity (DSP+RAM+CODEC, etc.) needs a single 5V supply. 

To make user's life easy there is a Gratz diode bridge and a voltage regulator 
on the board. The user should provide some 9-15V DC supply 

which will be then regulated down to 5V. 


My experience: I have taken one cheap "universal" wall-charger type power 
supply. This is basically a transformer, a diode bridge with a big electrolitic 
capacitor. I preset it to 9V, put this into the EVM56K and the whole setup 
seemed to work... until I tried some of my own programs. There were some 
strange sounds coming out of the EVM56K and the programs would crash sometimes. 
I checked that there is 9V at the input to the EVM56K but the line pulsing 
must have been strong enough and I think the voltage was monentary falling 
below the regulator's threshold. 

I preset the power supply to 12V then, and the problem was totally gone. 

But, I noticed another one: the regulator was getting a bit too hot. 

No surprise after all, if you go from 12V down to 5V at 500-700 mA you loose 
some watts on the regulator. 


I am saying this here to (1) warn the future EVM56K users and (2) to suggest 
to the designers of the extra PCB that it would be worth to put there 

a good power supply, maybe like in the DSPCARD4 ? 

Radio-amateurs mostly use 12-15V DC and the EVM56K gets too hot when running 
on this... 


Pawel 


